﻿__group__,ticket,summary,owner,component,_version,priority,severity,milestone,type,_status,workflow,_created,modified,_description,_reporter
Next Release,16567,Can't create categories with different names but similar slugs on Edit Post screen,,Administration,3.0.5,normal,normal,3.6,defect (bug),new,needs-unit-tests,2011-02-15T18:29:10Z,2013-01-09T23:38:54Z,"We run a blog that deals with programming languages. Today we were creating a post concerning the C programming language and attempted to create a new category for it, called ""C"" (just one character). This angered WordPress; it appeared to create a superfluous ""Uncategorized"" category, but it wound up not actually creating any categories for the post.

I've attached a screenie so you can see what this looks like after I attempt to create the category.

If it's for some reason forbidden to create categories comprised of a single character, maybe a validation error message of some kind would be in order?",jeffreymcmanus
Next Release,23930,Screen option for post formats UI,,Administration,trunk,normal,normal,3.6,feature request,new,needs-unit-tests,2013-04-03T18:28:10Z,2013-05-14T18:16:58Z,"As discussed in IRC, there should be a screen option for the post format UI on the post editing screen.

Nacin would like the UI to be hidden by default when the current theme does not support post formats and there are no non-standard format posts in the database. In this case, the UI would have to be enabled by the user. The UI would need to be automatically enabled when a theme that supports post formats is activated.

Willing patchers, make yourself known.

See also #23929

IRC logs:

https://irclogs.wordpress.org/chanlog.php?channel=wordpress-dev&day=2013-02-18&sort=asc#m558297

https://irclogs.wordpress.org/chanlog.php?channel=wordpress-dev&day=2013-04-03&sort=asc#m588002",johnbillion
Next Release,23216,"Create ""WP Heartbeat"" API",,Administration,,normal,normal,3.6,task (blessed),new,needs-docs,2013-01-16T20:41:50Z,2013-06-05T03:15:22Z,"The purpose of this API is to simulate bidirectional connection between the browser and the server. Initially it will be used for autosave, post locking and log-in expiration warning while a user is writing or editing.

The idea is to have a relatively simple API that sends XHR requests to the server every 15 seconds and triggers events (or callbacks) on receiving data. Other components would be able to ""hitch a ride"" or get notified about another user's activities.

In the future this can be used to block simultaneous editing of widgets and menus or any other tasks that require regular updates from the server.",azaozz
Next Release,17653,Canonical Redirect when space(s) are used instead of hyphens when requesting a page,dd32*,Canonical,3.2,normal,normal,3.6,enhancement,accepted,needs-unit-tests,2011-06-02T01:25:08Z,2013-02-21T01:15:53Z,"Create a page with a slug that contains a hyphen (eg. /page-name/).

If you then visit /page name/ (ie. use a space instead of a hyphen), WordPress currently manages to locate and display the page-name page. This could cause duplicate content issues.

The same issue occurs if multiple spaces are used instead of a hyphen.

As an example, this is the original page: http://jamesc.id.au/test-page/

This page is accessible via:
* http://jamesc.id.au/test%20page/
* http://jamesc.id.au/test%20%20page/
* http://jamesc.id.au/test%20%20%20page/
* http://jamesc.id.au/test%20%20%20%20page/

and so on.

WordPress should either output a 404 error, or redirect to /page-name/.

Tested using the latest 3.2 trunk (r18110).",jamescollins
Next Release,22692,Quotes Are Messing Up,,Formatting,3.4.2,normal,normal,3.6,defect (bug),new,needs-unit-tests,2012-12-03T09:39:36Z,2013-04-21T18:57:27Z,"Paste this into the body of a new post:

{{{
A sentence.  ""A quote after 2 spaces.""
}}}

Preview that, and be amazed.  The first quote is backwards.  :(

Due to font differences, this is easiest to see on the Twenty Ten theme.",miqrogroove
Next Release,23706,Image metadata encoding problem,,Media,3.0,normal,normal,3.6,defect (bug),new,needs-unit-tests,2013-03-06T17:05:43Z,2013-03-07T19:09:32Z,"I uploaded picture DSCF4480.jpg (attached for testing).

Metadata for title and caption should be the same: ""Bystřice u Benešova"". But after upload title is right, but caption is damaged:

{{{
'caption' => 'Bystøice u Beneova',
'title' => 'Bystřice u Benešova'
}}}

Using latest trunk.",pavelevap
Next Release,21970,404 error when a post has the same slug as with a deleted (trash) page.,,Permalinks,3.4.2,normal,normal,3.6,defect (bug),new,needs-unit-tests,2012-09-22T20:25:04Z,2013-04-23T20:14:25Z,"I don't know if this is a bug/issue but I'll share this anyway.

A user creates a new '''Page''', for example, with a title ""New Garden"". But decides to delete it/""Move to Trash"" without deleting it permanently. Then creates a new '''Post''' with the same title ""New Garden"". Viewing that post will result to a ""404"" page not found.",janintia
Next Release,13459,Conflict between post and page slugs/permalinks when permalink setting is set to /%postname%/,ryan,Permalinks,2.9.2,normal,normal,3.6,defect (bug),new,needs-unit-tests,2010-05-20T04:56:27Z,2013-06-17T17:22:35Z,"If Dashboard -> Settings -> Permalinks is set to /%postname%/, it is possible to create both a page and a post with the same slug. When viewing via the frontend, the page is always displayed.

I would have thought that WordPress should prevent a post and a page from having the same permalink.

Steps to reproduce:
1. Create and publish a page with any slug. eg. http://domain.com/test/.
2. Create and publish a blog post with the same slug. Wordpress says the permalink for the blog post is http://domain.com/test/, but when you visit that URL it displays the page instead.

I can reproduce this on my 2.9.2 install, as well as 3.0 trunk. I'm guessing the bug is present in earlier versions of WordPress as well.


Possibly related: #11863",jamescollins
Next Release,17817,do_action/apply_filters/etc. recursion on same filter kills underlying call,,Plugins,3.4.1,normal,normal,3.6,defect (bug),reopened,needs-unit-tests,2011-06-16T18:04:04Z,2013-05-21T21:16:44Z,"Affects @wp-includes/plugin.php: do_action, do_action_ref_array, apply_filters, apply_filters_ref_array, _wp_call_all_hook

When calling a specific hook from a function that was called through that same hook, the remaining hooked functions from the first iteration will be discarded.[[BR]]
This is due to the handling of the array of registered functions using internal array pointers instead of a more robust approach.

In my example, this problem arose when I tried to programmatically delete a menu in reaction to the removal of a category. I hooked into the delete_term action to do so, upon which another function hooked into delete_term would no longer fire.[[BR]]
The obvious workaround is to adjust the priorities accordingly, but it shouldn't be necessary.


The current implementation as in apply_filters is:
{{{
reset( $wp_filter[ $tag ] );

if ( empty($args) )
	$args = func_get_args();

do {
	foreach( (array) current($wp_filter[$tag]) as $the_ )
		if ( !is_null($the_['function']) ){
			$args[1] = $value;
			$value = call_user_func_array($the_['function'], array_slice($args, 1, (int) $the_['accepted_args']));
		}

} while ( next($wp_filter[$tag]) !== false );
}}}

Using the following method instead, both iterations would develop properly:
{{{
if ( empty($args) )
	$args = func_get_args();

foreach ( $wp_filter[$tag] as $filters )
	foreach( (array) $filters as $the_ )
		if ( !is_null($the_['function']) ){
			$args[1] = $value;
			$value = call_user_func_array($the_['function'], array_slice($args, 1, (int) $the_['accepted_args']));
		}
}}}",kernfel
Next Release,24159,Chats with spaces in the 'speaker' not parsing correctly,,Post Formats,trunk,normal,major,3.6,defect (bug),new,needs-unit-tests,2013-04-22T17:37:04Z,2013-05-17T22:53:29Z,"Since #23625 is closed and we were asked to make a new ticket, the issue I mentioned still remains.

Related to #23947 - currently this is broken in instances where chat names have spaces.

​http://test.ipstenu.org/testing-1.2013/

That has the post content as follows:


{{{
Nigel Tufnel: The numbers all go to eleven. Look, right across the board, eleven, eleven, eleven and…

Marti DiBergi: Oh, I see. And most amps go up to ten?

Nigel Tufnel: Exactly.

Marti DiBergi: Does that mean it’s louder? Is it any louder?

Nigel Tufnel: Well, it’s one louder, isn’t it? It’s not ten. You see, most blokes, you know, will be playing at ten. You’re on ten here, all the way up, all the way up, all the way up, you’re on ten on your guitar. Where can you go from there? Where?

Marti DiBergi: I don’t know.

Nigel Tufnel: Nowhere. Exactly. What we do is, if we need that extra push over the cliff, you know what we do?

Marti DiBergi: Put it up to eleven.

Nigel Tufnel: Eleven. Exactly. One louder.

Marti DiBergi: Why don’t you just make ten louder and make ten be the top number and make that a little louder?

Nigel Tufnel: These go to eleven.
}}}

But nothing shows.

You can see the exact same issue here: http://twentythirteendemo.wordpress.com/2013/02/10/never-say-never-say-never/

James Bond's lines are never shown.",Ipstenu
Next Release,17689,Terms should not be sanitized inside term_exists(),,Taxonomy,3.2,normal,normal,3.6,defect (bug),new,needs-unit-tests,2011-06-05T03:49:48Z,2013-06-17T13:20:20Z,"When adding a term to a post, the title of the term is sent through term_exists(). If term_exists finds and returns the ID of an existing term for the passed taxonomy, that ID is added to the post object. If no term is found, it returns false and a new term is created for that taxonomy with the same title that was passed to term_exists().

The problem is that term_exists() uses sanitize_title($term) on line 1457 of wp-includes/taxonomy.php while wp_insert_term uses stripslashes($name) on line 1985 of the same file.

This doesn't cause a problem in many circumstances, but if the term title happens to be something like $$$, that means it will always be added correctly in wp_insert_term() but never found as existing in term_exists(). The result is that every time you add $$$$ to another post it gets added as a new term with a unique slug so that you have  several terms with the title $$$$ for the same taxonomy but different IDs. 

The attached patch corrects that by passing the term title through stripslashes in term_exists() rather than through sanitize_title().

I haven't found any undesired side effects in testing.",blepoxp
Next Release,23219,Duplicate enclosure metadata created because of disagreement on meta field formatting,,XML-RPC,2.8,normal,normal,3.6,defect (bug),new,needs-unit-tests,2013-01-16T21:48:42Z,2013-04-29T03:10:09Z,"Years ago I reported an issue in Ticket #7773 that the enclosures would be duplicated each time the post was edited and resubmitted through the XMLRPC API. That bug was fixed in [10383] but a nuance was overlooked that causes this kind of duplication to occur with every edit if the ORIGINAL custom field meta for the enclosure was generated by the automatic content-scraper in WordPress.

If a post with links to ""enclosure"" type files is submitted either through the web interface or through the XMLRPC API, it will automatically generate the insertion of enclosure metadata as a custom field with fragile-structured content of the format:

{{{add_post_meta( $post_ID, 'enclosure', ""$url\n$len\n$mime\n"" );}}}

But the XMLRPC implementation, where the attempt is made to avoid generating duplicates, uses a slightly different fragile template, with no trailing newline:

{{{$encstring = $enclosure['url'] . ""\n"" . $enclosure['length'] . ""\n"" . $enclosure['type'];}}}

To make a long story short: the attempt to detect an existing enclosure on the post always fails because the existing enclosure string has a newline, and the XMLRPC-based one does not.

I propose that this be fixed by at enacting 1 and probably also 2:

1. Make sure duplicate detection method insensitive to trailing whitespace. This will fix the bug in a way that doesn't require retroactively ""fixing"" the existing stored metadata with trailing newline.

2. Change the format of the ""scraped"" enclosure generation to match the format used by XMLRPC. Either with or without the newline would probably be fine, but it seems cleaner to stick with the one that doesn't require a trailing newline, just three blobs of text separated by newlines. It also seems lucky that the last blob is a MIME type and thus would never have a meaningful newline at the trailing end.

I'm attaching a patch that achieves both of these goals. I report this to the XML-RPC component because that's the impact is, even if some of the issue is in the default scraping code from functions.php.

I'm a little less certain about how to tackle a unit test for these cases, but if somebody wants to point me in the right direction I can take a hack at that too.
",redsweater
Future Releases,11531,Some taxonomy names should be disallowed,ryan,Cache,2.9,normal,normal,Future Release,defect (bug),new,needs-unit-tests,2009-12-20T14:30:46Z,2013-05-16T15:05:44Z,"I haven't tested, but can't we can get all sorts of weird bugs (some of which could have potential side effects in the security department) if a term taxonomy is called users, userlogins, posts, etc.?

the reason are lines such as:

{{{
wp_cache_add($term->term_id, $term, $term->taxonomy);
}}}
",Denis-de-Bernardy
Future Releases,14485,Taxonomy hierarchy cache isn't properly refreshed,,Cache,3.0,high,normal,Future Release,defect (bug),new,needs-unit-tests,2010-07-31T03:11:13Z,2013-04-30T20:46:25Z,"I've developed a plugin that can create parent and children categories at the same time. It works well at 2.8.6 but it doesn't work as what I expect at 3.0.

When I create new parent and children categories at the same time, it only shows parent category in the Categories dashboard, but the children category is actually created. If I create another category or delete one category, the children category shows up. I think it should be a problem of wordpress cache, but I have no idea where to start tracing.

I use wp_create_category at wp-admin/includes/taxonomy.php to create categories. Besides, I have tried clean_term_cache but it didn't help. And I didn't activate other plugins when I tested this plugin.

It happened exactly when creating NEW parent and children categories.",thealien
Future Releases,15256,?cat=## permalinks do not redirect when category is a parent,,Canonical,3.0.1,high,normal,Future Release,defect (bug),reopened,needs-unit-tests,2010-10-30T05:44:18Z,2013-02-25T13:08:53Z,"One of my plugin users reported this while using dropdowns to display his categories: http://wordpress.org/support/topic/plugin-my-category-order-multiple-widget-support-broken

I was able to duplicate it on my own site in 3.0.1. Any category that has children displayed in the dropdown will redirect to /?cat=## instead of the the friendly /category-name permalink when selected. Select any other category or one of the children and they redirect correctly.

Any thoughts?",froman118
Future Releases,21700,Problem obtaining the Feed of an archive of tag “RSS”,,Canonical,3.4.1,normal,normal,Future Release,defect (bug),new,needs-unit-tests,2012-08-27T10:40:33Z,2013-05-24T16:15:58Z,"I'm using RSS as a tag for some of my blog posts, and I was using them without any problem.

'''myblog.com/tag/rss/'''

But I've just realised that Google Webmaster Tools gives me some related errors.

The issue is this: when trying to retrieve the feed of this tag, from

'''myblog.com/tag/rss/feed/'''

it gets redirected to

'''myblog.com/tag/feed/'''

And this gives an error.",xavivars
Future Releases,18734,Subcategory archive does work with any name as parent category in URL,,Canonical,3.0.1,normal,normal,Future Release,defect (bug),new,needs-unit-tests,2011-09-21T15:10:46Z,2012-10-22T23:10:00Z,"Parent category is ''parentcategory'' and his sub category is ''subcategory''.

The URL will be ''domain.com/category/parentcategory/subcategory''.

The problem is, that you will get the same page if you use any words as ''parentcategory''.

Examples:
- ''domain.com/category/xxx/subcategory''
- ''domain.com/category/subcategory''
- ''domain.com/category/foo/bar/subcategory''

IMO {{{redirect_canonical}}} should do his work here (and sometimes it does).

In 3.1 it does redirect.
In 3.1.4 it doesn't redirect; after r17549.
In 3.2.1 it doesn't redirect.
Duck_ found that it does redirect before r18079.
In current trunk it doesn't redirect.


",ocean90
Future Releases,21602,redirect_canonical can lead to infinite loop on index navigation if site url is not all lower case,,Canonical,,normal,normal,Awaiting Review,defect (bug),new,needs-unit-tests,2012-08-15T21:31:17Z,2013-04-23T07:53:55Z,"The function redirect_canonical in wp-includes/canonical.php (WordPress 3.4.1) on line 406 and 422 makes the following check:


{{{
if ( !$redirect_url || $redirect_url == $requested_url )
		return false;
}}}


This ensures that it does not attempt to redirect you to the page you requested in the first place. However this function is not case sensitive so if the redirect URL is in a different case than the requested URL then the user can enter an infinite redirect loop. (For example if the Site Address (URL) of the site is set to be in all upper case.) 

This function should do a case-insensitive string comparison since domain names are case-insensitive.


The issue only appears to happen with certain plugins installed (ShareThis and PilotPress both led to this issue,) I haven't figured out yet why it's only an issue with certain plugins but it should still be fixed in WordPress to make the proper string comparison. ",sreedoap
Future Releases,10543,Incorrect (non-UTF-8) character handling in tag's name and slug,westi*,Charset,2.8.2,normal,normal,Future Release,defect (bug),accepted,needs-unit-tests,2009-08-04T05:26:11Z,2010-11-13T01:15:40Z,"Incorrect (non-UTF-8) character tag's name and slug are handled in different way: name is truncated on 1st such character, and in slug they are just removed (no truncation). WP should handle both in the same way - drop invalid characters, instead of truncation.

I found this issue recently. One of the Polish programs for adding posts to the Wordpresses does not encode tags in UTF-8 - it left them in ISO-8859-2. I notified author of this bug. Unfortunately there are many copies around, so it may take a long time before everyone upgrade.",sirzooro
Future Releases,11175,wp_check_invalid_utf8() should drop invalid utf-8 chars only instead of truncating string,hakre,Charset,2.9,normal,normal,Future Release,defect (bug),new,needs-unit-tests,2009-11-18T19:18:43Z,2011-07-13T09:46:51Z,"When you call wp_check_invalid_utf8() with 2nd param set to true, it tries to strip invalid utf-8. Now it removes 1st invalid utf-8 char and all chars after it, no matter if they are correct or not. Additionally it can print following notice:

Notice: iconv() [function.iconv]: Detected an illegal character in input string in .../wp-includes/formatting.php on line 437

Attached patch changes this, so function removes invalid chars only. Additionally it is less configuration-dependent, because it can use either mb_convert_encoding() or iconv().",sirzooro
Future Releases,18997,Adding wp_unschedule_hook function,arena,Cron,3.3,normal,normal,Future Release,feature request,reopened,needs-unit-tests,2011-10-19T07:45:11Z,2012-04-20T00:02:54Z,"
Unschedule all previously scheduled cron job for a hook.

Can be usefull for plugins when deactivating to clean up the cron queue

The $hook parameter is required, so that the events can be identified.

@param string $hook Action hook, the execution of which will be unscheduled.
",arena
Future Releases,9993,Rss and atom feeds are dropping some characters,,Feeds,2.7.1,normal,normal,Future Release,defect (bug),new,needs-unit-tests,2009-05-31T23:54:40Z,2012-10-17T19:40:12Z,"Blog post with title:

{{{
& > test <
}}}

has the less than ( < ) is stripped from the atom and rss feed.

",pm24601
Future Releases,19543,Broken formatting when using HTML5 <section> element,,Formatting,3.3,normal,normal,Awaiting Review,defect (bug),new,needs-unit-tests,2011-12-14T10:32:07Z,2012-10-12T18:25:51Z,"When using <section> HTML5 element, the resulting markup is invalid because some paragraphs isn't closed properly. 

Reproduced with WP 3.3, TwentyEleven theme and no plugins. 

Example markup attached to this ticket. Paste into html view of the WYSIWYG editor and publish. Resulting markup also attached. ",exz
Future Releases,3833,Extra </p> inside blockquote,Archibald Leaurees,Formatting,2.7,normal,normal,Future Release,defect (bug),new,needs-unit-tests,2007-02-21T19:01:26Z,2012-09-10T22:08:20Z,"When using blockquote </p> is inserted directly in front of </blockquote>, making the code invalid XHTML.

Example:
{{{
<blockquote>This is a blockquote</blockquote>
}}}

Gives the following result:
{{{
<blockquote>This is a blockquote</p></blockquote>
}}}

Seems like [http://wordpress.org/support/topic/106474 this forum thread] adresses the same issue in the support forum.",audwan
Future Releases,4857,More issues with wpautop(),mdawaffe*,Formatting,2.3,low,normal,Future Release,defect (bug),accepted,needs-unit-tests,2007-08-29T06:47:01Z,2009-11-28T06:33:01Z,"''Not sure if this should slide into 2.3 or if it can wait for 2.4. Change as need be.''

`wpautop()` has issues with closing `</p>`'s when it comes to HTML.

For example:

{{{
Foo<div>Bar</div>
}}}

Results in:

{{{
<p>Foo
<div>Bar</div>
}}}",Viper007Bond
Future Releases,8775,Numbers in quotation marks get wrong smart quotes,,Formatting,2.8,normal,normal,Future Release,defect (bug),reopened,needs-unit-tests,2009-01-01T18:05:14Z,2013-05-01T15:41:31Z,"Have a number in quotation marks, such as {{{""12345""}}} or {{{'12345'}}} and {{{wptexturize}}} converts the right quotation mark to double-prime and prime marks, respectively.

Patch fixes.",filosofo
Future Releases,20943,Paragraphs get removed in table cells when Visual editor is refreshed,,Formatting,3.2,normal,normal,Awaiting Review,defect (bug),new,needs-unit-tests,2012-06-13T19:06:04Z,2013-04-18T16:14:03Z,"As far as I know, this issue has been around since 3.1.  It's not a bug in 3.0.4.  I even stopped upgrading at 3.0.4 for any sites where I knew the client would need to edit tabular data.  For security reasons, it's time to upgrade these and I'd REALLY like this issue to be fixed.

The problem happens when using paragraphs in a table cell.  When I hit enter to create a new paragraph within a table cell, it looks fine.  If I then hit Update/Publish, when the page refreshes, WordPress converts that paragraph break into a single line break.  If I then click Update again, WordPress removes that linebreak entirely and the paragraphs are essentially merged.

I can also reproduce this behaviour without even clicking Update.  If you just switch to HTML mode and then back to Visual mode, the same issue occurs.",JboyJW
Future Releases,20304,Strikethrough does not work for multiple paragraphs in the post editor,,Formatting,3.4,normal,normal,Future Release,defect (bug),new,needs-unit-tests,2012-03-25T20:13:00Z,2012-05-24T07:32:15Z,"'''Overview'''

If you have multiple paragraphs of text in the text editor and select all of them and push the strikethrough button, the text appears to be striked through; however, upon publishing/updating, only the first paragraph of text retains the strikethrough.

'''Steps to Reproduce'''

1) In a new post write screen add two paragraphs of text.

2) Select all of the text

3) Click the strikethrough button

4) Viewing the HTML of the rich text editor through web inspector (note that I am not toggling the visual/html tabs) shows:


{{{
<del>
	<p>text</p>
	<p>text</p>
</del>
}}}


5) Save post 

6) The text in the textarea only has strikeout for the first paragraph.

7) When viewing the source of the content on the front end, you get the following HTML:


{{{
<p>
	<del>text
</p>
<p>text</p>
<p>
	</del>
</p>
}}}


'''Other Information'''

I have tried these same steps on a clean install of 3.3.1. The strikethrough works as expected, and produces in all scenarios:


{{{
<p>
	<del>text</del>
</p>
<p>
	<del>text</del>
</p>
}}}

		
I first had this issue crop up for a .com client approximately 3-4 weeks ago, so this issue may have been introduced with a more recent patch.",tollmanz
Future Releases,19028,make_clickable fails when <a ...> contains \r characters,,Formatting,3.2.1,normal,minor,Awaiting Review,defect (bug),reopened,needs-unit-tests,2011-10-22T07:00:35Z,2011-11-02T00:34:43Z,"Hi.

I'm using the make_clickable php function in my project SaltOS to add the links feature to the email client and feeds reader.

I detect that when try to make clickable the urls that has the link tag and this tag contains \r characters it fails.

I fixed the problem removing all \r of the <a ...> tag but understand that can be a possible bug.

Thanks in advance.",josepsanzcamp
Future Releases,23922,make_clickable() breaks when colon in hash,,Formatting,,lowest,minor,Awaiting Review,defect (bug),new,needs-unit-tests,2013-04-03T00:41:39Z,2013-04-03T19:31:00Z,"`make_clickable()` doesn't like this string:

{{{
<a href=""http://en.wikipedia.org/wiki/URI_scheme#tel:"">http://en.wikipedia.org/wiki/URI_scheme#tel:</a>
}}}

It results in this HTML:

{{{
<a href=""http://en.wikipedia.org/wiki/URI_scheme#tel:""><a href=""http://en.wikipedia.org/wiki/URI_scheme#tel"" rel=""nofollow"">http://en.wikipedia.org/wiki/URI_scheme#tel</a>:</a>
}}}

Specifically it's the colon that is causing the issue. It can be a part of the URL too, it doesn't have to be a part of an anchor.",Viper007Bond
Future Releases,15657,wp_strip_all_tags causes paragraphs to run together,,Formatting,2.9,normal,normal,Future Release,defect (bug),new,needs-unit-tests,2010-12-03T06:05:40Z,2011-12-27T20:49:30Z,"If a post contains HTML like ""foo<p>bar"", the RSS feed ends up with the text ""foobar"" instead of the more appropriate ""foo bar"" or even ""foo\n\nbar"".

Here is a simple patch to wp-includes/formatting.php that fixes this: basically, convert <p>, <br> and certain similar tags to newlines before calling the PHP-builtin strip_tags() function.
",jwz
Future Releases,4116,wp_texturize to defect certain links in comments and on page,Nazgul,Formatting,2.2.1,normal,normal,Future Release,defect (bug),reopened,needs-unit-tests,2007-04-09T13:29:33Z,2010-11-23T04:53:07Z,"the wp_texturize() function in formatting.php (includes) of wordpress breaks links of the domain format (number)x(number). 

For example, a comment left by a domain such as www.h4x3d.com, which includes the (4)x(3) in the domain name, renders to www.xn--h43d-rma.com. This breaks the link.

It does occur on the page, but also with in the page comments. 
It does also occur when the text with the special combination is not a link, but plain text.",h4x3d
Future Releases,2833,wpautop breaks style and script tags,,Formatting,2.0.3,low,normal,Future Release,defect (bug),reopened,needs-unit-tests,2006-06-17T20:36:00Z,2012-09-09T21:01:21Z,"When I create a post in which I want to include Javascript or some styles, WordPress 'breaks'when showing those posts, because all newlines in the SCRIPT and STYLE tag are converted into BR tags.

Example:
{{{
<style type=""text/css>
.matt { color: #FFFFFF; }
</style>
}}}
Becomes:
{{{
<style type=""text/css><br />
.matt { color: #FFFFFF; }<br />
</style><br />
}}}

And:
{{{
<script type=""text/javascript""><!--
google_ad_client = ""xxxxxxxx"";
google_ad_width = 120;
google_ad_height = 60;
google_ad_format = ""120x60_as_rimg"";
google_cpa_choice = ""CAAQ2eOZzgEaCD4zuVkdzt_CKI-293M"";
//--></script>
}}}
Becomes
{{{
<script type=""text/javascript""><!--<br />
google_ad_client = ""xxxxxxxx"";<br />
google_ad_width = 120;<br />
google_ad_height = 60;<br />
google_ad_format = ""120x60_as_rimg"";<br />
google_cpa_choice = ""CAAQ2eOZzgEaCD4zuVkdzt_CKI-293M"";<br />
//--></script><br />
}}}

This happens because wpautop adds those BR tags to the post. (As it should, just not within STYLE or SCRIPT tags.)

I've made a (temporary?) workaround for this by creating a pre and post event for wpautop, which substitute the necessary newlines by a temporary value in the pre event and placing them back in the post event. Although I think this should be incorporated in wpautop itself.

See also: http://wordpress.org/support/topic/76433 and http://wordpress.org/support/topic/76297

While searching trac I also found ticket #2346, which is about the same problem, but which was for 2.0 and self-closed by the submitter?

P.S. I have TinyMCE turned of.",Nazgul
Future Releases,8912,wptexturize malforms HTML comments that contain HTML tags,,Formatting,2.7,normal,normal,Future Release,defect (bug),reopened,needs-unit-tests,2009-01-21T20:16:08Z,2013-03-18T15:01:17Z,"Because it's replacing -- with #8211, a comment like <!-- whatever --> put into the HTML part of a post gets broken.

This makes it difficult for people writing special HTML in posts (like people putting in object tags, or javascript, or whatever) to do that sort of thing.

What is needed is to recognize --> as different from -- and not replace it with the en dash in that case.
",Otto42
Future Releases,24556,wptexturize() edge case bug with specific sentence structure,,Formatting,,normal,normal,Awaiting Review,defect (bug),new,needs-unit-tests,2013-06-10T22:15:29Z,2013-06-11T03:00:41Z,"I discovered a very very edge case bug with `wptexturize()` where the below text will be output with the opening quote as the closing quote html entity (e.g. `&#8221;`) instead of the opening quote html entity (e.g. `&#8220;`) as expected.

Here's the text. The words can be replaced with anything else as long as they follow the same pattern.

{{{
Uppercase. ""Uppercase lowercase word-with-apostrophe's lowercase lowercase""
}}}

Here's how it gets output on the front-end:

[[Image(https://dl.dropbox.com/s/zbrilmyoo8awkjo/2013-06-10%20at%203.08.39%20PM.png)]]

The exact same problem happens regardless of the theme used. I can also consistently reproduce on WordPress 3.5.1 as well as with trunk. No plugins installed.

I've tracked the bug down to the, [http://core.trac.wordpress.org/browser/trunk/wp-includes/formatting.php#L89 opening quote regex] in `wp_texturize()`.

My regex foo isn't good enough to figure out a proper solution here unfortunately.",jkudish
Future Releases,19308,"C-style hexadecimal is incorrectly ""fixed"" to change the 'x' into a mathematical '×'",,Formatting,2.1,normal,normal,Awaiting Review,enhancement,new,needs-unit-tests,2011-11-21T00:39:00Z,2011-11-30T16:49:55Z,"Pretty much what the title says. I'm running trunk. ""0x07"" gets converted to ""0×07"".

I've attached a patch which fixes this issue by not performing the conversion if the first number starts with a zero -- this is not perfect, and I might have a go at something better when it's not 0030, if you guys decide this should be changed.

My $0.02 - since it's a bit odd to multiply zero by something, I don't think that very many people will expect/want this conversion to happen -- and the lack of conversion is unlikely to confuse those that do. 

On the other hand, this conversion is confusing for any blog post using this hex notation, and does make those posts actually wrong.

",harrym
Future Releases,6969,Don't apply wptexturize() to the insides of shortcode tags,tellyworth,Formatting,2.5.1,normal,normal,Future Release,enhancement,new,needs-unit-tests,2008-05-14T11:47:58Z,2011-05-31T08:45:13Z,"I have this for my post contents:

{{{
[code lang=""php""]$foo = 'bar';[/code]
}}}

The problem is my shortcode function gets this passed to it for the content string:

{{{
$foo = &#8216;bar&#8217;;
}}}

`wptexturize()` should be smart enough to not format the contents of registered shortcodes. If plugins want their contents formatted, they can pass the contents to the `wptexturize()` function itself.",Viper007Bond
Future Releases,20522,the sanitize_file_name_chars filter and ch(0),,Formatting,,normal,minor,Awaiting Review,enhancement,new,needs-unit-tests,2012-04-23T08:26:28Z,2012-04-24T00:41:12Z,"the sanitize_file_name_chars filter is tricky to use due to the chr(0) ending the array :

both 
{{{
special_chars[] = $my_char; 
}}}
and 
{{{
array_push($special_chars, $mychar);
}}}
have no effect.

so the only way to add some char to the array is to use array_unshift :
{{{
array_unshift($special_chars, $mychar);
}}}

adding 

this is mostly a php issue, but it could be useful to add some notice to the WordPress documentation.

",olivM
Future Releases,13340,wpautop breaks inline MathMl,,Formatting,2.9.2,normal,normal,Future Release,enhancement,new,needs-unit-tests,2010-05-11T14:04:58Z,2012-04-07T01:41:16Z,"wpautop treats inline &lt;math&gt; tags as block; they in fact may be placed block or inline, with their flow model dependent on the mode or CSS display property.

Trivial to fix; just needs someone to commit the change. Remove ""|math"" from $allblocks in file wp-includes/formatting.php. math tags on their own will be wrapped in a paragraph, which is fine.

As a very convenient enhancement, please replace on line 210:

{{{
     if ($br) {
-        $pee = preg_replace_callback('/<(script|style). ....
+        $pee = preg_replace_callback('/<(script|style|math) ...
}}}

to prevent MathML being polluted with breaks (current required workaround people are using is to have the whole block on one line, which is very messy to edit).",nicholaswilson
Future Releases,14754,add_query_arg() refactoring,,General,,normal,normal,Future Release,defect (bug),new,needs-unit-tests,2010-09-01T16:32:20Z,2011-03-23T19:34:24Z,"The function add_query_arg() looks like that it could benefit from a refactoring. Especially the handling of optional parameters (did introduce PHP 4 that language feature?) can benefit by a sligh touch-up.

Attached patch reflects only the first few lines of the function.",hakre
Future Releases,23881,get_transient() could delete transient timeout options in an unexpected way,,General,2.8,normal,minor,Future Release,defect (bug),new,needs-unit-tests,2013-03-28T11:02:07Z,2013-04-22T21:17:24Z,"get_transient() could delete transient timeout options if a given transient name has the ""timeout_"" prefix.

To reproduce:
{{{
set_transient( 'test', 'test', 60*60 );
get_transient( 'timeout_test' ); // will delete the _transient_timeout_test option
}}}

Solution:

Check if get_option( $transient_timeout ) is not returning false.
{{{
if ( false !== get_option( $transient_timeout ) && get_option( $transient_timeout ) < time() ) {
}}}
",tenpura
Future Releases,16943,Code Cleanup add_query_arg() + friends,,General,3.1,normal,normal,Awaiting Review,enhancement,new,needs-unit-tests,2011-03-23T05:41:22Z,2011-03-23T07:11:27Z,"This should reduce the complexity of add_query_arg() a bit.

This is partially related to PHP 5 stuff (#16918,#16920) we can make use of now.

Originated in #16932 

Related: #16942",hakre
Future Releases,16615,More inline docs needed to explain DB errors esp. dead_db() and effects of WP_DEBUG,,Inline Docs,,normal,normal,Awaiting Review,enhancement,new,needs-docs,2011-02-22T21:42:58Z,2011-02-23T06:29:19Z,"'''The Problem: DB Error reporting can't be modified'''

I'm trying to set my sites up for some scheduled downtime of our (separate) MySQL server. I am hoping that I can show cached pages if they are requested, but show a 'We are down for scheduled maintenance' message when a user loads a page that needs the database. 

In the process I'm seeing there are many different places in the code that fire depending on exactly how broken the database is. Specifically, there are some scenarios where `dead_db()`, which is totally different from the rest of the messages, will fire. dead_db() is cool because it promises to let us use a `/wp-content/db-error.php` file to control output in case of a db error, but currently it is just frustrating because most types of db error (server missing, db missing) don't cause `dead_db()` to fire, but instead use `$wpdb::bail()`. These bail()-based errors are used in wp-db.php. 

However `dead_db()` CAN still fire, which I know because our site often has database outages that result in the H2 from `dead_db()` being shown. I think it's a certain mix of ""the mysql server and database seem to exist, but are failing to respond to actual queries"". That said, I'm pretty sure that the scenarios where dead_db still fires are ones also covered by some of the `$wpdb::bail()` situations, and would be better off handled by one consistent system of errors. dead_db() should either be used for all DB related errors or deprecated, otherwise it is just an awkward red-herring for developers.

'''The Solution: Better filters on `$wpdb::bail()`'''

I think that all these messages need to be pluggable somehow and it should be clear how to do so when looking at the code itself. Asking people who want to change a wp_die() message to find it in the code is reasonable, but it should be clear from there how to change it. Ideally there would be a filter in the function that calls bail() that lets you edit the text and/or forward the user to another URL where a maintenance message lives. It should be of of those situations where finding the source of the message also finds the means of changing it.

The simplest answer would be a filter added in `$wpdb::bail()` that used the $error_code to identify the specific message. In the database errors the $error_code passed to bail() are useful slug-type strings like 'db_select_fail'. Something like:


{{{
apply_filters('wpdb_bail', $error_code, $message);
wp_die($message);
}}}



This would give people a lot of control, and could easily be referred to in a comment before any given instance of `$wpdb::bail()`.

To make the $error_code easier to find I think it's also worth reformatting the code used to call `$wpdb::bail()`. Currently it takes this form:

{{{
$this->bail( sprintf( /*WP_I18N_DB_CONN_ERROR*/""
...
SUPER LONG HTML MESSAGE
...
""/*/WP_I18N_DB_CONN_ERROR*/, $details['db_host'] ), 'db_connect_fail' );
}}}

This makes it hard to notice the 'db_connect_fail' string all the noise. Instead the message perparation and bail() call should be on two lines, one for defining the message and another that only calls bail (with an explanation about the $error_message and filter above it).

Looking at it deeper I imagine I can achieve what I want by hooking into the 'wp_die_handler' filter, checking for the exact HTML generated by the DB error (the `$message` value in the code above), and doing something based on that, but it's obviously a house of cards for future updates where the text might change. It will also be easily foiled by any translation of the `$message` which will change its output.


",jeremyclarke
Future Releases,16330,"media_sideload_image() broken with filenames containing strange characters (e.g., +, %)",,Media,3.1,normal,major,Future Release,defect (bug),reopened,needs-unit-tests,2011-01-21T13:56:19Z,2013-03-17T10:31:55Z,"I'm using the {{{media_sideload_image()}}} method in the upcoming version of my [http://wordpress.org/extend/plugins/e107-importer/ e107 Importer script] (see: http://github.com/kdeldycke/e107-importer/blob/b7925fdac6aa43db4be5b7925265a83d95fc62ad/e107-importer.php#L277 ) to upload remote images into WordPress.

This method work as expected with lots of images from a lot of different sources, but fail on URLs containing spaces.

Let me illustrate this bug with an example.

When trying to upload the image located at
{{{
http://home.nordnet.fr/francois.jankowski/pochette avant thumb.jpg
}}}
the result looks like this on the file system: http://twitpic.com/3s0dk7 . As you can see, image file names are clean. But in the Media Manager, here is what you have: http://twitpic.com/3s0e5d . No thumbnails seems to have been created.

Now, trying to fix this, I modified the original URL before calling {{{media_sideload_image()}}} with the following code:
{{{
  $img_url = str_replace(' ', '%20', html_entity_decode($img_url));
  $new_tag = media_sideload_image($img_url, $post_id);
}}}
With this patch, here is the result on the filesystem: http://twitpic.com/3s0ets . I was surprised by WordPress not sanitizing URLs. Is that normal ?

But the most surprising stuff is in the Media Manager: http://twitpic.com/3s0hup . It looks like thanks to this hack, WordPress somehow succeeded downloading the remote file but messed with filesystem naming. What let me think this ? The Media Manager, get the right image thumbnail dimensions but not the binary payload of the thumbnail (contrary to the case above were no binary nor dimensions are available about the thumbnail).

All of this was tested in WordPress 3.1-RC2.

As for the idea of the patch above, it come from a very old version of my plugin (v0.9) that was based on WordPress 2.3.2. There, I somehow found the root cause of the problem, [http://github.com/kdeldycke/e107-importer/blob/e107-importer-0.9/e107.php#L410 according the comment I wrote 3 years ago]:
{{{
 // The fopen() function in wp_remote_fopen() don't like URLs with space chars not translated to html entities
}}}

I should have posted this bug report sooner, as now I've forgotten everything about this issue... :(",Coolkevman
Future Releases,21959,No way to override the name of an image when that is being resized,,Media,3.4.2,normal,normal,Awaiting Review,enhancement,new,needs-docs,2012-09-21T16:34:23Z,2012-09-22T20:42:44Z,"The most obvious solution is to add a hook to allow the destination file name to be modified. 

The solution attached gives pretty much all the information you could possibly want to modify the filename as you might need to.",jkmassel
Future Releases,16282,PHP catchable error with get_term_link and WP3.1RC2,,Multisite,3.1,normal,major,Future Release,defect (bug),reopened,needs-unit-tests,2011-01-18T12:23:37Z,2011-03-08T23:10:45Z,"I recently updated my WP Network to 3.1RC2, and suddenly the get_term_link() I was using in the footer gave me this error:

  PHP Catchable fatal error: Object of class WP_Error could not be converted to string

It was working fine in 3.0.4",illutic
Future Releases,23865,Trailing slash is not enforced when editing the path for a subdirectory site in multisite,,Multisite,3.0,normal,normal,Awaiting Review,defect (bug),new,needs-unit-tests,2013-03-26T19:53:23Z,2013-04-01T09:38:28Z,"It is possible to edit an existing subdirectory site so that the path does not end in a trailing slash, this causes the subdirectory site in question to have an inaccessible home URL.

To reproduce:

 * Create a multisite network in subdirectory mode
 * Create a new subdirectory site
 * Visit the subdirectory site successfully
 * Edit the site to change the path so there is no trailing slash
 * You should be unable to visit the subdirectory site now",simonwheatley
Future Releases,22192,update_metadata() and update_option() strict checks can cause false negatives,,Performance,,normal,normal,Future Release,defect (bug),new,needs-unit-tests,2012-10-15T03:19:23Z,2012-10-15T10:22:31Z,"Given this:

{{{
add_post_meta( $post_id, 'key', 1 );
update_post_meta( $post_id, 'key', 1 );
}}}

The update should not work, because they are the same. However, the meta cache will have ""1"" as a string, and then it will strict compare it to 1 as an integer. Thus, an unnecessary update will run.

Best I can tell, this could also affect update_option().

It is quite common to use integers and booleans directly into these functions. They should be smart enough to recognize that ""1"" == 1 == true and ""0"" == 0 == false, and that any numeric string is also equal to a properly cast integer.

Unit tests needed.

Ticket from which this was spun: #22189, saving navigation menus is slow.",nacin
Future Releases,22074,Very Large Query that Crashes the whole My SQL and site,,Performance,3.4.1,normal,normal,Future Release,enhancement,new,needs-unit-tests,2012-10-02T03:13:14Z,2013-05-16T11:59:00Z,"Hi David,

The problem is being caused by an extremely large mysql query. This is just a snippet of it. The full query is in /home/profithunters/query. You should have your dev look at it.

What user/pass are you using for mysql? You can login as the root mysql user by logging into https://profithunters.nmsrv.com/gadmin/ and then going to MySQL -> Launch phpmyadmin.
{{{
       | 370           | 371       |
| 1697 | profithu_wrdp2 | localhost | profithu_wrdp2 | Query   | 78   | statistics           | SELECT * FROM wp_posts  WHERE (post_type = 'page' AND post_status = 'publish')  AND ( ID <> 3778  AND ID <> 49911  AND ID <> 0  AND ID <> 20531  AND ID <> 3776  AND ID <> 3792  AND ID <> 3794  AND ID <> 3797  AND ID <> 3799  AND ID <> 3801  AND ID <> 3803  AND ID <> 3805  AND ID <> 3807  AND ID <> 3811  AND ID <> 5540  AND ID <> 6500  AND ID <> 8965  AND ID <> 9363  AND ID <> 10974  AND ID <> 11516  AND ID <> 11822  AND ID <> 12903  AND ID <> 12907  AND ID <> 12911  AND ID <> 13928  AND ID <> 13930  AND ID <> 14188  AND ID <> 14192  AND ID <> 14935  AND ID <> 14937  AND ID <> 14939  AND ID <> 14941  AND ID <> 15023  AND ID <> 15376  AND ID <> 19768  AND ID <> 20980  AND ID <> 20984  AND ID <> 21353  AND ID <> 21550  AND ID <> 21554  AND ID <> 21559  AND ID <> 21562  AND ID <> 21618  AND ID <> 21623  AND ID <> 21629  AND ID <> 21674  AND ID <> 21677  AND ID <> 21682  AND ID <> 21689  AND ID <> 21694  AND ID <> 21703  AND ID <> 21706  AND ID <> 21707  AND ID <> 21714  AND ID <> 21717  AND ID <> 21744  AND ID <> 21834  AND ID <> 21859  AND ID <> 21862  AND ID <> 21865  AND ID <> 21873  AND ID <> 21876  AND ID <> 21880  AND ID <> 21884  AND ID <> 21897  AND ID <> 21900  AND ID <> 21902  AND ID <> 21905  AND ID <> 21936  AND ID <> 21938  AND ID <> 21940  AND ID <> 21949  AND ID <> 21951  AND ID <> 21958  AND ID <> 21966  AND ID <> 21983  AND ID <> 21986  AND ID <> 21989  AND ID <> 21995  AND ID <> 22000  AND ID <> 22004  AND ID <> 22006  AND ID <> 22010  AND ID <> 22014  AND ID <> 22016  AND ID <> 22020  AND ID <> 22024  AND ID <> 22026  AND ID <> 22028  AND ID <> 22030  AND ID <> 22037  AND ID <> 22040  AND ID <> 22043  AND ID <> 22046  AND ID <> 22049  AND ID <> 22058  AND ID <> 22060  AND ID <> 22062  AND ID <> 22065  AND ID <> 22068  AND ID <> 22071  AND ID <> 22073  AND ID <> 22075  AND ID <> 22078  AND ID <> 22085  AND ID <> 22087  AND ID <> 22089  AND ID <> 22094  AND ID <> 22125  AND ID <> 22128  AND ID <> 22133  AND ID <> 22137  AND ID <> 22141  AND ID <> 22144  AND ID <> 22151  AND ID <> 22153  AND ID <> 22155  AND ID <> 22157  AND ID <> 22160  AND ID <> 22162  AND ID <> 22165  AND ID <> 22168  AND ID <> 22170  AND ID <> 22172  AND ID <> 22174  AND ID <> 22176  AND ID <> 22178  AND ID <> 22180  AND ID <> 22184  AND ID <> 22186  AND ID
}}}",adest
Future Releases,17450,Almost pretty permalinks with non-ASCII characters do not work in Apache,westi,Permalinks,3.1,normal,major,Future Release,defect (bug),reopened,needs-unit-tests,2011-05-16T05:53:14Z,2012-04-27T19:03:50Z,Almost pretty permalinks (using PATH_INFO) with non-ASCII characters do not work in Apache; a not found error is returned. The same permalink works in IIS when UTF-8 is used for server variables. It also works when mod_rewrite is used.,peaceablewhale
Future Releases,10249,Page slug in cyrillic = Error 404 - Not Found!,westi*,Permalinks,2.7,normal,major,Future Release,defect (bug),accepted,needs-unit-tests,2009-06-23T19:44:34Z,2012-04-27T19:04:18Z,"When I create a page with page slug for example ""киро""
then when I try to open domain/киро - Error 404 - Not Found

The permalinks are %postname%

Post slug with this slug is working just fine, the same BUG exists in 2.7, 2.7.1 and 2.8",kalifi
Future Releases,9064,URLs with commas are not pinged,,Pings/Trackbacks,2.7,high,major,Future Release,defect (bug),new,needs-unit-tests,2009-02-07T11:07:20Z,2013-05-20T12:01:23Z,"I use following permalink format on my blog:[[BR]]
/%category%/%postname%,%post_id%[[BR]]
Unfortunately Wordpress doesn't ping them correctly - URLs extracted from post content don't have suffix with comma and post id.[[BR]]
[[BR]]
Fix: in file wp-includes/comment.php change line 1400 from:[[BR]]
$punc = '.:?\-';
[[BR]]
to:[[BR]]
$punc = '.:?\-,';
",sirzooro
Future Releases,24248,'guid' not properly escaped,,Post Types,2.5,normal,normal,Future Release,defect (bug),new,needs-unit-tests,2013-05-02T14:03:35Z,2013-05-10T20:37:34Z,"Probably related issues: #18274 #19248

'guid' being saved in database not properly escaped, example:
{{{http://www.wordpress.dev/?post_type=changeset&#038;p=57}}} , see the ampersand encode {{{&#038;}}}
It supposed to be {{{&}}} or at least {{{&amp;}}}

Once 'auto-draft' saved, 'guid' is correct: {{{http://www.wordpress.dev/?post_type=changeset&p=57}}}

Once post is saved as 'draft' or published (triggered 'update post' on auto-draft), 'guid' gets malformed.

Source of issue: inappropriate usage of {{{get_post_field()}}} function in the {{{wp_insert_post()}}}

{{{get_post_field()}}} defaults to 'display' context, we not specify context while obtaining field, and in the {{{wp_insert_post()}}} we are not going to display it anywhere, just get, check, and save again, correct?

Attached patch adds the 'raw' context to usage of {{{get_post_field()}}} with 'guid'

",meloniq
Future Releases,21963,Consolidate post insertion APIs,,Post Types,,normal,normal,Future Release,defect (bug),new,needs-unit-tests,2012-09-22T03:46:24Z,2012-12-27T15:14:44Z,"In wp-includes, we have:
 * wp_insert_post()
 * wp_insert_attachment()
 * wp_update_post()
 * wp_publish_post()

For saving from the admin, we have:
 * edit_post()
 * wp_write_post()
 * write_post()

'''wp_publish_post()''' is, as of [21942], now wraps wp_insert_post().

'''wp_update_post()''' is a fairly mundane wrapper of wp_insert_post(), but we really should eliminate the differences between the two functions and make it a straight-up wrapper.

'''wp_insert_attachment()''' was a fork of wp_insert_post(), and wp_insert_post() has gotten a lot of improvements that haven't reached wp_insert_attachment(). It doesn't take much to merge these two, though, and make wp_insert_attachment() a wrapper.

'''wp_write_post()''' calls edit_post() if it has a post ID. And since we have had a post ID since the days of auto-drafts, this function is dead code. It's wrapper, '''write_post()''', can also be deprecated.

I'm attaching a patch that takes care of wp_insert_post(), wp_write_post(), and write_post(). wp_update_post() will require a bit more concentration.

Needs testing and unit tests.",nacin
Future Releases,12706,Custom post status bugs in the admin,ptahdunbar,Post Types,3.0,normal,normal,Future Release,task (blessed),new,needs-unit-tests,2010-03-25T14:41:39Z,2013-06-05T06:59:18Z,"A developer should be able to register a custom post status using `register_post_status()`. The admin UI (including post submit box and quick edit) should reflect this new custom post status. Furthermore, there are many hard-coded references to 'draft' and 'pending' statuses in core that should properly use the post status API.

All existing arguments to `register_post_status()` should be fully implemented, should also support per-post-type arguments. As things get implemented across core, there will likely be a need for supporting capabilities and bits of API.

Related: #23169 (register_post_status_for_object_type), #23168 (unregister_post_status).",ptahdunbar
Future Releases,18386,"Bug in custom query when ""Front page displays"": ""A static page""",,Query,3.2.1,normal,normal,Future Release,defect (bug),new,needs-unit-tests,2011-08-12T10:34:16Z,2012-05-09T10:13:53Z,"Here is the bug I have found:
When Front page displays is set to: A static page
and Blog posts are displayed on other page a bug accours...

Lets prepare test enviroment, with clear wp installation and two posts, where one of them is set to default category, and other is set to newly created category (which defautly has ID = 3).
Now, prepare two pages, and in Setting -> Reading set Front page to one of those pages, and Posts page to second one.

If You would like to exclude posts from category no 3 from main blog index, normaly You would use:
<?php query_posts($query_string . '&cat=-3'); ?> in index.php (or specified loop file linked there).
This would work if blog index is set as home page, but fails to work when above test enviroment is used.",CyberSpy
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,21803,Add filter to make extending searching easier,,Query,3.4,normal,normal,Future Release,enhancement,new,needs-unit-tests,2012-09-05T13:50:13Z,2012-11-07T07:14:55Z,"I'm using custom post types, and want to extend the search function so more than post_title and post_content are searched. It is currently possible to filter `posts_search` but that returns a string such as ` AND (((wp_posts.post_title LIKE '%test%') OR (wp_posts.post_content LIKE '%test%'))) `. This string then has to be rather messily manipulated via `preg_replace` or `str_replace`.

It would be more useful if we could filter a list of fields to be added to the search criteria, so that we could add a function to extend or change the criteria:

{{{
add_filter ('search_fields', 'my_custom_search_fields');

function my_custom_search_fields ($fields) {
    global $wpdb;
    $fields[] = ""{$wpdb->prefix}posts.post_excerpt"";
    return $fields;
}
}}}

The attached patch implements that filter.",mark8barnes
Future Releases,17065,Independent ASC/DESC in multiple ORDER BY statement.,ericmann,Query,3.1,normal,normal,Awaiting Review,enhancement,new,needs-unit-tests,2011-04-06T17:11:01Z,2013-05-09T14:55:14Z,"WP_Query supports ordering results by multiple columns, but does not currently support independent ASC/DESC declarations on those columns.  Instead, it concatenates the ORDER and ORDER BY statements together.

In some cases, it would be beneficial to independently set the order for these columns.  An example offered on WP-Hackers:

> I have a situation where I want to order a list of post both by author and date using WP_Query which isn't a problem since 'orderby' lets me do that. But I want the author part sorted ascending and date part sorted descending.

A normal MySql statement would end with `ORDER BY author ASC, date DESC`.

We should extend WP_Query to allow users to set their ordering parameters independently.  This should be done in such a way as to not break backwards compatibility.",ericmann
Future Releases,19907,Updating an unpublished draft post in quick-edit mode sets the post's publish date,,Quick/Bulk Edit,2.7,normal,major,Future Release,defect (bug),new,needs-unit-tests,2012-01-27T14:51:32Z,2013-06-12T19:42:56Z,"'''Problem:'''

 • If you update an unpublished draft post in quick-edit mode, the post's ''publish date'' is saved. [[BR]]
 • Then, later on, when you actually publish the post, its publish date is incorrect.

'''Suggested fix:''' 

 • If the post is a draft, do not automatically set the post's publish date in quick-edit mode.

'''Steps to reproduce:''' 

(1) Go to WP-Admin -> Posts.

(2) Create and save a new post. Make sure you click ""Save Draft"" — not ""Publish"".

(3) Note that the post is marked as ""Publish immediately""; that is, it has no publish date.

(4) Go back to WP-Admin -> Posts.

(5) Hover your pointer over the post you just created. Click ""Quick Edit"". 
 — Note that in the panel that appears, the ""Date"" field is automatically set to [the current date and time].

(6) Click ""Update"" in quick-edit mode.

(7) Hover your pointer over the post you just updated. Click ""Edit"". 
 — Note that in the Edit Post page that appears, the post is now marked as ""Publish on: [the date and time from step (5)]""
",uxtremist
Future Releases,16303,Improve documentation and usability of WP_Rewrite Endpoint support,westi,Rewrite Rules,3.1,lowest,normal,Future Release,defect (bug),new,needs-docs,2011-01-19T16:25:01Z,2013-04-05T00:28:06Z,"When you know how it works the WP_Rewrite Endpoint support is really simple and cool.

When you don't it looks really difficult to use.

We should document it better and add an endpoint mask for Custom Post Types.",westi
Future Releases,18962,Allow duplicate slugs for different content,,Rewrite Rules,,normal,normal,Future Release,enhancement,new,needs-unit-tests,2011-10-16T16:23:34Z,2013-05-24T14:25:26Z,"Currently, the slug of a post (or any other CPT) must be unique. 
If a content is being created and an already existing slug is being assigned to it - WP will add a number for identification (i.e. about-2 etc).

That means, that if one has content from different content types, or in different categories (taxonomies), it still cannot have same slug.

The issue might be very disturbing when working in a multi lingual site (i.e using WPML or any other plugin for that).
Suppose there is an about page - www.mysite.com/about.
This is in the main language of the site.
Than a translation to that content page is being added,  let's say it is translation to English.
You would expect url something like www.mysite.com/en/about, but the slug is being changed to about-2, so the url of the about page in English becomes www.mysite.com/en/about-2.
For a site with 10 languages, let's say, it will end with urls like site.com/lang/about-10 etc.. and this is not looking good and may confuse.

As a cms, WP should let the admin/developer/operator - to have same slugs for different content types, or even in the same content type. The $post->ID is the unique identifier of a content, why should be also the slug?

",maorb
Future Releases,13701,Full support for middle and little endian permalink structures,,Rewrite Rules,2.9.2,normal,normal,Future Release,enhancement,reopened,needs-unit-tests,2010-06-02T14:34:08Z,2013-05-14T13:32:31Z,"This only happened after I switched over to the WordPress 3.0 development version, so I'm inclined to think it's a bug.  When I use the traditional wp_get_archives or the dropdown version it shows that posts exist.  However, when I click to go to any of those past posts, I only get a 404 Error.  This problem is very consistent, happening 100% of the time.  Disabling all plugins has no affect on the problem.

The only other information that might be helpful is that I've integrated WordPress into a website that I built and I am using a custom theme that I built.  It only has the index.php, single.php, and style.css files.

Again, the wp_get_archives function worked just fine with the exact same setup that I have now prior to switching to the 3.0 version, so I'm not sure what changed.",RevelationTravis
Future Releases,14481,Shortcode Enhancements,,Shortcodes,3.0,normal,normal,Future Release,enhancement,new,needs-unit-tests,2010-07-30T22:37:23Z,2010-10-31T13:34:44Z,"Somewhat of a copy of a post to wp-hackers: I wrote my own implementation of shortcodes. It does things a bit differently, has nested evaluation, and allows self-nesting. Since there are some significant differences to the existing implementation,

A lot of the changes are borrowed from definitions in the HTML specification (particularly name and attribute matching). The following are the comments at the top of my shortcode file. I tried to keep track of all the differences (and questions) there.

== From Test Cases ==

(http://svn.automattic.com/wordpress-tests/wp-testcase/test_shortcode.php)
{{{
Shortcode Statuses (to implement, or not to implement?)
        enabled = the shortcode works as normal (default)
        strip = the shortcode will be parsed and removed.  e.g.
'[shortcode foo=""bar""]' produces ''.  '[shortcode]foo[/shortcode]'
produces 'foo'.
        faux = the shortcode will be abbreviated.  e.g. '[shortcode
foo=""bar""]' products '[shortcode]'.  '[shortocde]foo[/shortcode]'
produces '[shortcode]'
        disabled = the shortcode is not parsed at all.  e.g.
'[shortcode foo=""bar""]' products '[shortcode foo=""bar""]'
}}}

== Major Differences/Improvements ==

I. Addressing http://codex.wordpress.org/Shortcode_API#Limitations

 1. You can nest any tag at any depth regardless of ancestors (#10702)

 2. Tag and attribute names may match: `/[A-Za-z][-A-Za-z0-9_:.]*//*` (trialing /* because that comment ends), with case-insensitive interpretation

 3. Interpretation doesn't get tripped up by things like hyphens

== II. Addressing Ticket #12760, ==

 1. Changed from fix in #6518. Reasoning: balancing double-square-brackets can have misleading results with nesting

 2. Shortcodes escapable by using `[[`, `]]`

 3. `]]` is escaped ""right to left"", so `[shortcode]]]` would evaluate to `result]`

 4. '[[' is escaped left to right `[[[shortcode]]]` => `[result]`

== III. Enhancements ==

 1. Only matches valid shortcode for registered hooks, everything else will appear as text

 2. Can register multiple hooks to single shortcode, uses priority (default: 10)

== IV. Conflicting Design Changes ==

 1. Quoted literals are escaped by entities rather than cslashes

 2. Inline (self-closing) shortcodes get passed content to accomodate multiple callbacks

 3. No equivalent to shortcode_parse_atts function (Not marked private in function reference, but not documented in shortcode API page)

 4. Boolean attributes take the place of positional attributes `[foo bar]` gets attributes `array('bar' => 'bar')` instead of `array('0' => 'bar')`

 5. Disallows attribute and tag names that don't match `/[A-Za-z][-A-Za-z0-9_:.]*/`

 6. Disallows unquoted attribute values (also boolean attributes), unless they match `/[-A-Za-z0-9_:.]+/`

== Basic Interpretation Method ==

 1. If an open tag is encountered, it is added to the stack

 2. If a close tag is encountered and there is no matching open tag on the stack the close tag is ignored

 3. If a close tag is encountered and there is a matching open tag on the stack all opened tags on the stack before the matched tag will be implicitly self-closed

 4. If text or an inline tag is encountered, it will be evaluated to its parent's content immediately

 5. If tags are not closed by the end of the interpretation, they will be implicitly self-closed

== Issues ==

 1. Haven't written new unit tests to reflect new functionality added, functionality differences

 2. Documentation is not as good (though I hope most of the code is self-explanatory)

 3. Not 100% backwards compatible",deadowl
Future Releases,12982,Shortcodes don't allow shortcodes in attributes,,Shortcodes,3.0,normal,normal,Future Release,feature request,new,needs-unit-tests,2010-04-12T22:31:17Z,2010-04-15T22:16:02Z,"I think that shortcodes should work when used inside attributes of other shortcodes, just like they can work inside the ""$content"" of a shortcode.

Some people says that that isn't supposed to work, but theoretically it is supposed to work when using the ""do_shortcode"" function. It don't work because:

1) ""do_shortcode"" is context free, which it's actually fine by its fastness, although it don't allow stuff like inserting a shortcode inside the content of itself

2) The shortcode regex stops with the first occurrence of a ] in a shortcode, so in this:

{{{[foo bar=""[baz /]""]content[/foo]}}}


it ""outputs"":


{{{[foo bar=""[baz /]}}}


and {{{""]content[/foo]}}} is ignored.

I'm not programmer but I tried to fix it by changing the shortcode regex so it allow anything between quotes or brackets inside the first group of brackets. It sort of works, but also mess the handling of quotes in the rest of the shortcode, so I think something more advanced have to be done to make it work. 

This is somewhat related to another shortcode tickets, but none of them addresses nor solves this specifically.",Atoon
Future Releases,14691,Allow commas in tag names,,Taxonomy,3.0.1,normal,normal,Future Release,enhancement,new,needs-unit-tests,2010-08-25T09:51:09Z,2012-06-07T03:56:55Z,"Adding tags to posts via the web interface involves a lot of what boils down to
{{{
explode( ',', join( ',', array( $tag_name, ... ) ) );
}}}
both in PHP and JS.

We settled on commas so we could have tags with spaces in them (see #10320, for example).

It'd be nice if tags (and other taxonomies) could have commas in them, though.  Example use case: normalized locations (""Portland, OR"").  Admittedly, commas in tag names is an edge case.

The attached treats tag inputs as ""real"" CSV strings instead of just exploding by commas.

That way, you can enter:
{{{
hello, ""hello, world""
}}}
in the tags input field and the following tags would be added to the post.
 * hello
 * hello, world

This addresses commas in tag names but makes entering double quotes in tag names more annoying.  If you wanted a tag named {{{double""quote}}}, you'd have to enter the following.
{{{
""double""""quote""
}}}

This may also help with #7897.",mdawaffe
Future Releases,15846,Posts list associated to a term_taxonomy_id,,Taxonomy,3.1,normal,normal,Future Release,enhancement,reopened,needs-docs,2010-12-16T15:38:55Z,2011-01-10T15:32:32Z,"It could be very useful to have in the core a function that retrieve the list of all the posts associated to a term id. I have written the follow one:

function posts_of_a_term_id($term_id, $limit){
	global $wpdb;
	
	$query = ""SELECT object_id FROM $wpdb->term_relationships WHERE term_taxonomy_id = $term_id ORDER BY object_id DESC LIMIT $limit"";
	$results = $wpdb->get_results($query);
						
	foreach($results as $result):
						
		$id = $result->object_id;
		query_posts('p='.$id.'');
		if ( have_posts() ) : 
			while ( have_posts() ) : the_post(); ?>
				<li><a href=""<?php the_permalink(); ?>""><?php the_title(); ?></a></li>
			<?php endwhile;
		endif;
		wp_reset_query();
							
	endforeach;
}",_DorsVenabili
Future Releases,21760,get_term_by() calls are not cached,,Taxonomy,2.3,normal,normal,Future Release,enhancement,new,needs-unit-tests,2012-08-31T21:26:22Z,2013-05-03T16:00:39Z,"{{{get_term()}}} is the simplest way to retrieve one term, but it requires {{{term_id}}} and {{{taxonomy}}}. Because of this, terms are cached with {{{term_id}}} as key and {{{$taxonomy}}} as bucket. As a result, you can't easily grab a term by slug, unless you use {{{get_term_by( 'slug' )}}}. {{{get_term_by( 'slug' )}}} and {{{get_term_by( 'name' )}}} don't even have a query cache, so they go to the database every time. Because you can't get a term by {{{slug}}} without hitting the db, every place you want to get a term by {{{slug}}}: you first have to transform it into a {{{term_id}}} where it will then be cached. This is inefficient because the user may query by {{{slug}}} constantly and never by {{{term_id}}}.",wonderboymusic
Future Releases,9547,Taxonomy - interesting 'unused' term_order column in table term_relationships.,ryan,Taxonomy,2.8,high,normal,Future Release,feature request,reopened,needs-unit-tests,2009-04-16T15:19:42Z,2013-05-14T14:06:03Z,"During development of plugin [http://wordpress.org/extend/plugins/xili-language/ xili-language], and to sort term by term list of languages in a taxonomy, I discover unused column '''term_order''' in ''term_relationships'' table and lack of functions in core about this column. Like medias in post, here the user can define languages list with first, second, third,... languages for his website (and xml header). Taxonomy tools are here very powerful without adding tables or annoying coding.

([http://plugins.trac.wordpress.org/browser/xili-language/tags/0.9.8.2/xili-language.php  see code here line 1309-1370]). 

Before to complete these very basic functions,…

Is it forecast to have more basic / generic functions using '''term_order''' in taxonomy.php ?

[http://core.trac.wordpress.org/ticket/9546 Related ticket]",michelwppi
Future Releases,18302,Improve child theme file inheritance by introducing `theme_url()` to locate a file URI,westi,Template,,normal,normal,Future Release,enhancement,reviewing,needs-unit-tests,2011-07-31T01:19:02Z,2013-04-22T19:02:43Z,"Child theme file inheritance isn't quite as slick as it could be. A child theme should be able to selectively override any of its parent theme's files (ie. CSS & JS), not just template files.

For example, there's no easy way for a parent theme to enqueue a JavaScript file that can be easily overridden by a child theme. This is because there's no URI version of `locate_template()` for themes to use.

Example: A parent theme includes a JavaScript file like so:

{{{
wp_enqueue_script( 'foo', get_template_directory_uri() . '/foo.js' );
}}}

A child theme couldn't simply include a `foo.js` file to override its parent's as the file is always loaded from the template directory, not the stylesheet directory. If the parent theme used `get_stylesheet_directory_uri()` instead, then the child theme could override it '''but''' it would '''have''' to override it, otherwise we'd end up with a file not found.

The answer is to introduce a function that does the same as `locate_template()` but returns a URI instead of a path.

Example usage:

{{{
wp_enqueue_script( 'foo', locate_theme_file( 'foo.js' ) );
}}}

This would load `foo.js` from the child theme if it existed, and the parent theme if not.

The function could also be used for CSS files:

{{{
wp_enqueue_style( 'bar', locate_theme_file( 'bar.css' ) );
}}}

And for images too:

{{{
<img src=""<?php echo locate_theme_file( 'icon.png' ); ?>"" />
}}}

Stand by for a patch.",johnbillion
Future Releases,15086,get_template_part() should let you specify a directory,westi*,Themes,3.0,normal,normal,Future Release,enhancement,accepted,needs-unit-tests,2010-10-10T21:36:45Z,2013-02-07T21:51:35Z,"IT would be nice for `get_template_part()` to allow you to specify a directory to look for a file in.  Right now you actually *can* do this, but it requires passing a 'slug' to the function like `directory/slug`.  Since everywhere else in the code slugs are sanitized, this seems like an unexpected way to allow this functionality (I didn't realize this worked until @nacin pointed it out).  Since this slug isn't actually sanitized at all, you can currently do `get_template_part( '../../../test' );` which seems rather unsafe (`get_template_part` should be able to include from outside the themes directory).

I suggest sanitizing $slug and adding a third [optional] parameter that allows you to specify the directory to look in.  The directory parameter should be sanitized enough to not allow it to start with a . or a / (although this more likely belongs in `locate_template()` as something done to $template_name inside the foreach).

What does everyone think about this approach?

How many themes do we think are currently using the $slug parameter to specify a directory?

Right now the optional $name parameter is set up as a fall through, so if $slug-$name.php doesn't exist $slug.php is used.  Should $directory be set up similarly ($directory/$slug-$name.php -> $directory/$slug.php -> $slug-$name.php -> $slug.php)?",aaroncampbell
Future Releases,20652,"Install plugins with FTP upload, virtual subdomain, bad base dir?",dd32,Upgrade/Install,3.3.2,normal,normal,Future Release,defect (bug),reopened,needs-unit-tests,2012-05-10T12:02:48Z,2013-05-21T19:58:48Z,"Hi anybody!
I have problem with install plugins with FTP module in WP.

Everything show as OK, but plugin directory is bad. I have subdomain

sub.something.com - this is virtual subdomain from mod_rewrite

dirs are

/www/something.com/something.com[[BR]]
/www/something.com/sub.something.com - here is WP installation, subdomain is virtual from rewrite in httpd.conf

After install - WP say everything OK - but one thing is bad.[[BR]]
Upload is in bad directory - plugin I can found in[[BR]]
/www/something.com/something.com/plugins[[BR]]
no in /www/something.com/sub.something.com/plugins[[BR]]

Is here some way to fix it automatticaly or I can must edit config and basedir of ftp? Why is here this bug?

Thank you !

Pavel
",rajcz
Future Releases,22212,WP_User_Query( array('role' => $role) ) should accept array or not return anything if array,,Users,,normal,normal,Awaiting Review,enhancement,reopened,needs-unit-tests,2012-10-17T12:37:43Z,2013-03-26T22:52:38Z,"I got a small problem with WP_User_Query - i wanted to find users from more then one roles to send them e-mail, so i did


{{{
$role = array('role-1','role-2);
$wp_user_search = WP_User_Query( array('role' => $role) );
$users = $wp_user_search->get_results()
foreach ($user) ... send wp_mail
}}}


problem is, that role param accepts only string. It would not be a problem if it would return nothing, problem was, that it actually returns ALL users, so i have send my author-only emails to all thousands users in database :-(

I know that it is my fault, that i have to read documentation, but i thought, that it works as other wp queries, so if the parame do not fit, it throws error, but it does not.",thomask
Future Releases,15058,Validate option and transient name lengths,,Validation,3.1,normal,normal,Future Release,enhancement,new,needs-unit-tests,2010-10-07T15:37:46Z,2013-05-17T15:52:23Z,"The option_name column in the options table holds up to 64 characters yet there aren't any length checks to ensure that the length isn't exceeded. This leads to all sorts of odd behavior as the name will be truncated to fit, saving the option but not allowing it to be retrieved with the same name.

This issue affects all uses of the options system. A particular annoyance is transients. A transient that doesn't expire has a max name length of 53 characters yet a transient that does expire has a max name length of 45 characters. When attempting to save an expiring transient of name length between 46 and 53 characters, the transient will store but will be deleted before being used when get_transient is called due to the missing _transient_timeout_ option (since it was too long).

The core issues are that the functions don't return any type of failure condition on names that are too long and no warning is created. So, I've created a patch that addresses both of these issues.

The patch shows an example of how option and transient name length validation can be added. In order to allow users to modify the option_name column length, a new constant, WP_OPTION_LENGTH, is created with a default value of 64. This constant is checked for all length validation.

This is simply an example of how I'd like the validation to function. I'm not attached to the wording of the warnings or the name of the constant.",chrisbliss18
Future Releases,11160,Inconsistancies in Naming and Using Sidebar Names and IDs.,azaozz,Widgets,2.9,normal,normal,Future Release,defect (bug),new,needs-unit-tests,2009-11-17T12:58:55Z,2012-11-22T03:18:21Z,"register_sidebar() allows more sidebar names and IDs to be registered than dynamic_sidebar() recognizes as valid names and IDs.

For example, register_sidebar() allows me to name a side bar ""1"" with a id of ""first"". I don't know why anyone would choose those values, but register_sidebar() allows it [1].

{{{ register_sidebar( array('name' => 1, id => 'first') ); }}}


dynamic_sidebar() will not be able to find the sidebar given its name (1).
{{{
    if ( is_int($index) ) {
        $index = ""sidebar-$index""; /// 1 becomes 'sidebar-1'
        ...
}}}
The main problem is that dynamic_sidebar() is trying to process both IDs and names through the same variable ($index) while register_sidebar() separates the two with an array ( array('name' => 'Top', 'id' => 'sidebar-1' ).

According to the in-line docs for dynamic_sidebar():

    It is confusing for the $index parameter, but just know that it should just work. When you register the sidebar in the theme, you will use the same name for this function or ""Pay no heed to the man behind the curtain."" Just accept it as an oddity of WordPress sidebar register and display.


It does ""just work"" if you never use your own sidebar IDs.


I started looking at this because I wanted to use is_active_sidebar() which tests to see if a dynamic_sidebar() has anything in it. There is no get_dynamic_sidebar(). dynamic_sidebar() sends everything to the browser or returns false.
{{{
    register_sidebar( array('name' => 'Top') ); // id defaults to ""sidebar-1""
    ...

    if ( is_active_sidebar('Top') )
        dynamic_sidebar('Top');
}}}
Which fails because is_active_sidebar() just completely skips over searching for an id to go with a name. To get it to work you need to know when it was registered. Not something theme authors and designers are going to follow easily. There's a ticket to fix this: [http://core.trac.wordpress.org/ticket/10440 #10440]
{{{
    if ( is_active_sidebar(1) )
        dynamic_sidebar('Top');
}}}
Like dynamic_sidebar(), is_active_sidebar() converts 1 to ""sidebar-1"". Unlike dynamic_sidebar() it assumes everything is entered as an id.


unregister_sidebar() assumes its parameter (incorrectly named $name, not $id) is an id. But it wants a literal id, like ""sidebar-1"". unregister_sidebar(1) unregisters a sidebar with an id of 1, while dynamic_sidebar(1) tries to display a sidebar with an id of ""sidebar-1"".


=== Widgets (Admin Page) ===

The dynamic_sidebar() function is used by the Widgets management page. So, it is possible to create a sidebar with register_sidebar() that dynamic_sidebar() cannot find. You can populate it with drag and drop [2] and not have it appear on the web site.


== After Patch ==

If committed, this patch would remove the need for tickets [http://core.trac.wordpress.org/ticket/10440 #10440] and [http://core.trac.wordpress.org/ticket/10956 #10956]. It changes the current argument behavior of unregister_sidebar(), but doesn't break backward compatibility. It allows is_active_sidebar(), unregister_sidebar() and dynamic_sidebar() all point to the same sidebar.

=== Before ===

These all refer to the same sidebar:
{{{
	is_active_sidebar(1);
	unregister_sidebar('sidebar-1');
	dynamic_sidebar('Sidebar Top');
}}}

In an admittedly contrived case, dynamic_sidebar() would silently fail to allow this sidebar to show:
{{{ register_sidebar( array('name'=>'Sidebar Top', 'id' => 1) ); }}}



=== After ===
These all refer to the same sidebar (the first two would have broken before the patch):
{{{
	is_active_sidebar('Sidebar Top');
	unregister_sidebar('Sidebar Top');
	dynamic_sidebar('Sidebar Top');
}}}

After the patch this shows fine:

{{{ register_sidebar( array('name'=>'Sidebar Top', 'id' => 1) ); }}}

After the patch it is possible to force an argument to be only a name or only an id:
{{{
	is_active_sidebar(array( 'name' => 'Sidebar Top' ));
	unregister_sidebar(array( 'name' => 'Sidebar Top' ));
	dynamic_sidebar(array( 'id' => 1 ));
}}}



=== Notes ===

[1] register_sidebar() allows the user to override the default setting of: 'id' => ""sidebar-$i"",

[2] When you refresh the Widgets management page the widgets will disappear from the sidebar. They are still attached to a sidebar, but dynamic_sidebar() cannot see the sidebar.",CharlesClarkson
Future Releases,11387,Walker Widget System,ShaneF*,Widgets,,normal,normal,Future Release,enhancement,accepted,needs-docs,2009-12-10T16:56:00Z,2011-01-08T19:34:01Z,"This is a new system for Widgets. The design for this system is based on the fact that every theme is different.

Currently the widget system does not care about one theme. It will still output it's own formating structure based on it's design and then bassed on a messy 'register_sidebar' arguments wrap that data inside one another.

The idea behind a Walker Widget system is that instead of the Widget outputing the data, it send it to a Walker where it assigns the relevant information and the theme's ""Widget Design"" class holds how Widget boxes are created based on the values pushed through the walker.

For example in my theme functions.php file:

{{{
class Walker_Widget_Rabbit extends Walker_Widget {

	function start_widget($args, &$output) {
		
		// @todo Updated with the correct vars.
		$output .= do_action('sidebar_before_module', $id);
		$output .= do_action('sidebar_before_module_' . $id);
		
		$output .= sprintf( ""<div id='%s' class='module widget %s'>"", $args['widget_id'], $args['classname'] );
	}
	
	function title_widget($args, &$output) {
		$output .= ""<div class='head'><h3>"" . $args['title'] . ""</h3></div>"";
		/*
		if ((bool) $this->get_option('scrolling') && $scroll['enabled']) { 
			printf(__(""navi: <a id=\""prev_%s\"">prev</a>&nbsp;/&nbsp;<a id=\""next_%s\"">next</a>""), $scroll['key'], $scroll['key']);
		} 
		*/
	}

	function content_widget($args, &$output) {
		$output .= ""<div class='wrap'>"" . $this->content_style($args, $args['output']) . ""</div>"";
	}

	function content_style($args, $output) {
		
		/*
		 * Here I am going to figure out how we are going to wrap most content
		 * and detirme if the information is scrolled information.
		 */

		$style = $args['style'];
		switch ($style) {
			case 'none': 
				$style = $output; 
				break;
			default: 
				$style = ""<ul class='dash-strip'>"" . $output . ""</ul>"";
		}
		return $style;
	}
	
	function content_scroll($args, $area = 'top') {
		//	@todo <div class=""content-scroll-large""> and <div class=""content-scroll"">
	}
	
	function end_widget($args, &$output) {
		$output .= ""</div>"";
		// @todo Updated with the correct vars.
		$output .= do_action('sidebar_after_module', $id);
		$output .= do_action('sidebar_after_module_' . $id);
	}
	
}
}}}

This also allows users to manipulate the data/design even further once they get it from the widget.

I have tested this on the default theme of WordPress with the all 12 of the built in WordPress widgets and they act/look just like if it was hardcoded into the system itself.
",ShaneF
Future Releases,20630,XML-RPC Extending documentation for methods called with a single param,,XML-RPC,,normal,normal,Awaiting Review,defect (bug),new,needs-docs,2012-05-07T18:47:46Z,2012-05-07T19:06:01Z,"When an XML-RPC method is called with a single parameter, the method will receive the value directly instead of receiving an array with a single value. This seems to be intended, though unexpected, behavior. The documentation should be updated to mention this.

The related code is inside IXR_Server->call().",scott.gonzalez
Future Releases,16985,XML-RPC endpoint set the datetime when saving a Draft,,XML-RPC,3.1,normal,normal,Future Release,defect (bug),new,needs-unit-tests,2011-03-28T13:33:46Z,2012-06-24T00:15:12Z,"When uploading a draft post from one of the WordPress mobile apps the post date is set to the current time/date, even if the datetime field is not specified on the client request.
This could cause issues, because when you change the post status to ""publish"" it will be published using the date set during the first upload.

On the web dashboard if you do not set the post datetime explicitly, it is not set and hitting publish will then populate the datetime field with the current time.

The same happens if you start a draft on the web and then you publish it using any mobile apps.

details here: http://ios.trac.wordpress.org/ticket/826",daniloercoli
Future Releases,20026,Adding a post_type filter in wp.getComments,westi,XML-RPC,,normal,normal,Future Release,enhancement,reviewing,needs-unit-tests,2012-02-12T15:48:53Z,2012-08-05T19:45:16Z,This will be usefull when with the new custom post type support in XMLRPC,nprasath002
Future Releases,23099,Add JSON-RPC support using existing XML-RPC methods,,XML-RPC,3.5,normal,normal,Future Release,feature request,new,needs-unit-tests,2013-01-02T01:22:37Z,2013-04-22T21:18:54Z,"Many people have expressed interest in a JSON API for WordPress core. Until a full REST API can be implemented, the existing XML-RPC method implementations can be re-used by wrapping them in JSON-RPC serialization/de-serialization logic.",maxcutler
