_filename ticket Milestone type summary workflow component version severity priority modified _description
26802.diff 26802 Awaiting Review WordPress FTP component fails to update core on IIS7+ needs-patch Filesystem API 3.7.1 major normal 2014-01-18T05:38:19Z "Update fails with this error : Could not copy file.: wp-admin/update-core.php
Steps to reproduce :
* Clean install of Windows 2012R2 in a virtual machine
* PHP version 5.4.23 installed, configured, and tested as per Microsoft Instructions
* Granted FTP user full control of entire web root
* Granted web server user read access to web root
* Verified the ability to connect with a remote FTP client, create a folder, upload a file, delete the file, delete the folder
* Installed wordpress 3.7.1
* Logged into wordpress admin, clicked on 3.8 upgrade link
* prompted for FTP credentials, supplied same credentials as in my test above
* wordpress update failed with the following message
{{{
Downloading update from https://wordpress.org/wordpress-3.8-new-bundled.zip…
Unpacking the update…
Verifying the unpacked files…
Preparing to install the latest version…
Enabling Maintenance mode…
Copying the required files…
Disabling Maintenance mode…
Could not copy file.: wp-admin/update-core.php
Installation Failed
}}}
I then verified that the update could be done manually via an FTP client
* Manually downloaded wordpress-3.8-new-bundled.zip form wordpress.org
* Manually unzipped into temporary directory
* Manually uploaded contents of entire zip file to server
* ran wp-admin/update-core.php
* Updated the database as prompted
Wordpress successfully updated to 3.8 using this manual FTP upload method. The only difference is that I used my own FTP client (Filezilla) instead of the wordpress FTP component.
I think its fair to say at this point that there is a potential bug in the FTP component which manifests itself on IIS servers.
WWW, FTP, and PHP Log files are available upon request.
"
WP_Request.php 18322 Future The Road to Magic Quotes Sanity needs-patch Bootstrap/Load 3.2.1 major normal 2011-10-02T04:21:46Z For back compat reasons, wp_magic_quotes() performs addslashes() on GPCS data. This is a pain, especially given that some core API expects slashes and some doesn't. In hopes of someday losing the automatic GPCS slashing, let's introduce a flag to turn off the slashing as well as slash and unslash functions that consult the flag. If slashing is on, these functions add and strip slashes. If slashing is off, they return data unchanged. Plugin authors can start using these functions and testing their code with GPCS slashing turned off and on. Eventually, GPCS slashing would default to off and all calls to the slash and unslash functions could be removed from core.
11694.diff 11694 Future WP should do sanity checks for paginated posts, pages and comments has-patch Posts, Post Types 2.9 major normal 2010-04-02T08:22:39Z "Create a post with two pages using the tag. Publish, and browse the post's *third* page.
WP should return a 404 here, rather than the last page of the post.
Along the same lines, it should return the correct canonical urls for paginated posts. Currently, rel=canonical will only ever return the post's first page."
wpdb-injector.php 29710 Awaiting Review Add hooks to wpdb's insert(), update(), delete() and similar methods 2nd-opinion Database 2.5 normal normal 2015-07-28T01:43:45Z "The `wpdb` class currently offers a `query` filter in its `query()` method which supplies ''unstructured'' data to its handlers (a string with an SQL query). In our plugin we need to work with ''structured'' data provided to the `insert()`, `update()` and similar methods. It would be great if these methods provided hooks both before and after the actual work happens.
For instance, the `insert()` method would become:
{{{
function insert( $table, $data, $format = null ) {
do_action( 'db_before_insert', $table, $data, $format );
$result = $this->_insert_replace_helper( $table, $data, $format, 'INSERT' );
do_action( 'db_after_insert', $table, $data, $format, $result );
return $result;
}
}}}
"
33053.diff 33053 Awaiting Review download_url() includes query string in temporary filenames has-patch Upgrade/Install 4.2.1 normal normal 2015-07-21T09:09:28Z "When installing a theme update, I encountered an error traced back to the update file exceeding the Windows path\filename length limit. It turned out the root cause of this was that the download URL contained a query string with access key information, which was also being included in the filename of the temporary file created by $tmpfname = wp_tempnam($url); in the download_url() function.
In my case, for example, download URL was:
https://s3.amazonaws.com/marketplace-downloads.envato.com/files/140862862/enfold.zip?AWSAccessKeyId=*******************&Expires=1437422162&Signature=*****************-***********%3D&response-content-disposition=attachment%3B+filename%3Dthemeforest-4519990-enfold-responsive-multipurpose-theme-wordpress_theme.zip
which resulted in a temporary file called:
enfold.zipAWSAccessKeyId*******************Expires1437422162Signature*****************-***********-3Dresponse-content-dispositionattachment-3B-filename-3Dthemeforest-4519990-enfold-responsive-multipurpose-theme-wordpress_theme.tmp
rather than the expected enfold.zip
I would suggest that downloaded files should probably exclude any query string from the URL as the simplest method of resolving this issue, but will leave that to development team."
32878.diff 32878 Awaiting Review More readable regular expressions for Press This URL's has-patch Press This normal normal 2015-07-03T12:23:01Z "The regular expressions in Press This are hard to read.
The attached patch does (probably among other things)
- Switches to using `!` instead of `/` as the delimiter, so that `/` doesn't need escaping inline
- Removes the escaping of `?` and `.` within character maps `[.?]` as they don't need escaping there
- Adds case-insensitive matching to most expressions, aside from `/wp-includes/`
- Removes the usage of `{1}` as a single-character match is implied
- Not certain what `preg_match( '/\/ad[sx]{1}?\//', $src )` was supposed to match (`/ad/`, `/ads/`, and `/adx/`? If so, it's not currently matching `/ad/`, which this patch changes)
The patch is untested so far, needs to be reviewed to check I didn't miss anything."
5vPGCCt7.diff 32452 Awaiting Review Cache optimizations needs-patch Cache API 4.1 normal normal 2015-05-21T03:13:54Z "Hi,
I've recently been making some custom modifications to wordpress core that reduce the resource load on our object-caching system.
I cannot see any drawbacks to these modifications, but I have to defer to the wp-core development team on this one and therefore assume I've missed something.
I want to know if there is anything I overlooked while making these modifications.
If there are no drawbacks, then perhaps the changes could be rolled into wp-core officially (and then I won't have svn showing files as modified all the time)
Explanation: (broken down into sections)
1) I noticed a huge amount of 'extra' queries to the object-cache.
Many of them originating from calls to wp_load_alloptions()
I believe with my modifications wp_load_alloptions() only needs to be called in one place instead of many, and that is within the definition of the object-cache itself.
2) I've also reduced redundant queries by changing the assumption that a key doesn't exist to a key does exist. Check the cache for the key first instead of checking the 'negative' cache for the key first.
3) Some minor fixes in options.php
---- removed untrailingslashit on line#109 // function does not yet exist if called from within functions.php
---- added ! $result == 0 line#288 // if a database update effects zero rows the cache should still be updated
---- pre-emptively negatively cache (into notoptions) the just deleted option line#477
All file changes (from svn diff) available at this link:
http://pastebin.com/5vPGCCt7"
29204.diff 29204 Awaiting Review SimplePie error with fetch_feed() needs-patch Feeds 3.8 normal normal 2015-03-09T05:37:04Z "There seems to be a bug in SimplePie that raises the following notice every time an RSS Feed Dashboard widget is added to the Dashboard.
{{{
call_user_func_array() expects parameter 1 to be a valid callback, non-static method WP_Feed_Cache::create() should not be called statically on line 215 in file /path/to/wp-includes/SimplePie/Registry.php
}}}
Calling `fetch_feed()` is the best way to raise it. I'm using 'blackbox-debug-bar' plugin to capture the notices.
Examples to reproduce the error:
Install and use [https://wordpress.org/plugins/dashboard-feed-widget/ Dashboard Feed Widget]
or follow one of the tuts below.
http://adamscottcreative.com/add-your-own-news-feed-to-wordpress-dashboard/
http://samglover.net/build-your-own-wordpress-dashboard-widget-for-any-rss-feed/
I suspect the reason we don't see it when ""WordPress News"" is displayed is because the fetch_feed() runs via ajax and does not get captured in the current screen."
certificate-data.txt 26955 Awaiting Review AddTrust External CA Root Certificate not recognized needs-patch HTTP API 3.8 normal normal 2014-02-05T03:04:16Z "Hi all,
At our server, we are using the PositiveSSL CA 2 certificate by Comodo. When a wp_remote_get request is made, the server tries to verify the SSL certificate by wp-includes/certificates/ca-bundle.crt. AddTrust doesn't exist in this file so the verifyssl is false. We've discovered this in the W3 Total Cache plugin when we tried to activate minify and page cache.
Best,
Danny"
26494.2.diff 26494 Awaiting Review Plugins page errors should use 'error' class rather than 'updated' commit Plugins 3.8 normal normal 2013-12-09T04:55:35Z "Just noticed that some errors on the plugins page are using the Informational notification colours instead of an error colour.
It makes sense that we should update these."
25741.diff 25741 Awaiting Review Broken WP_Filesystem methods has-patch Filesystem API normal normal 2013-10-28T03:18:22Z "The following methods of WP_Filesystem do not work as intended, as they're called with absolute paths, and fail to find those absolute paths within the relative paths returned from the listing functions:
* WP_Filesystem_FTPext
* owner()
* getchmod()
* group()
* WP_Filesystem_ftpsockets
* owner()
* getchmod()
* group()
It's worth noting that the following FTP methods are available but don't actually hit the filesystem, and are just there to match the `WP_Filesystem_Direct` methods:
* is_readable()
* is_writable()
* atime()
* touch()
Attached is a patch I had locally from during 3.7 development, not thoughly tested, I believe WP_Filesystem_FTPext::owner() at least needs extra work.
The patch also removes the above methods from the FTP classes and relies upon the `WP_Filesystem_Base` versions - as a result, the is_writable() and is_readable() methods changed to assume things are readable/writable."
18826.diff 18826 Awaiting Review wp_maintenance() expiration time needs to be filterable 2nd-opinion Upgrade/Install 3.3 normal normal 2013-08-21T07:18:46Z ".maintenance files expire after 10 minutes if something goes wrong. 10 minutes is a long time, when most upgrading operations are attempted and fail within 20-60 seconds.
I propose three things:
1. changing the default expiration to 5 minutes (300 seconds)
2. Adding a filter to allow plugins and themes to filter this time to increase/decrease it
3. Also, while I was in there, it seems prudent to attempt to delete the file if it has expired. The only argument I could see against this is that possibly it might be expensive if the file can not be deleted and wp attempts to delete the file on every page load. So I can take or leave 3 (and 2), but #2 I think is really important."
argus.php 16808 Awaiting Review Insufficient permissions for custom post type management and custom role/caps needs-patch Role/Capability 3.1 normal normal 2013-08-09T07:07:48Z "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."
22239.diff 22239 Awaiting Review wp_ob_end_flush_all() tries to destroy non-destroyable output buffers needs-patch Bootstrap/Load normal normal 2012-10-21T03:27:28Z "`wp_ob_end_flush_all()` currently tries to flush & destroy every PHP Output buffer that is enabled on the current installation.
However, not every type of PHP Output buffer can be destroyed, which will cause a PHP Notice when attempts to do so are made.
An example of this is PHP extensions such as New Relic, or PHP output buffers created with the `$erase` flag set to false in `ob_start()`
An example is when New Relic is installed on a host, also [https://newrelic.com/docs/php/php-agent-faq#rum-obclean see New Relics FAQ entry] on the issue.
{{{
( ! ) Notice: ob_end_flush(): failed to send buffer of New Relic auto-RUM (1) in ../trunk/wp-includes/functions.php on line 2641
Call Stack
# Time Memory Function Location
1 0.8510 4328360 shutdown_action_hook( ) ../load.php:0
2 0.8510 4328440 do_action( ) ../load.php:556
3 0.8510 4329856 call_user_func_array ( ) ../plugin.php:406
4 0.8510 4329888 wp_ob_end_flush_all( ) ../plugin.php:406
5 0.8511 4330064 ob_end_flush ( ) ../functions.php:2641
}}}
Somewhat similar to #18239
I'm not sure of what the ideal solution for this would be for !WordPress, but wanted to record the issue being known."
18385.patch 18385 Awaiting Review "Canonical redirections not suited for Queries with multiple query vars and ""pretty permalinks"" in general" dev-feedback Canonical 3.2 normal normal 2011-08-12T09:06:32Z "When the Canonical code was originally written, it served it's purpose quite well. However, over the years the number of Query vars which can be used to access content via has increased, and so have the number of archive views. This has lead to increased complexity in the Taxonomy canonical code which has needlessly caused bugs.
What I'm proposing, is that it might be time to lay to rest the current `if.. elseif.. elseif..` style checks, It's not possible for 1 if branch to handle every single access point without duplicating another branch.
As a result, I've put a half-finished together alternate version of Canonical, It's based on tallying up which query vars have been used/accounted for and removing any duplicates.. It's certainly not the best, but it's fairing better with the unit tests so far.
{{{
Unit Testing: http://unit-tests.trac.wordpress.org/browser/wp-testcase/test_includes_canonical.php
Before: FF.......FFFF..FFF.....F......FFFFFF.F....F.....FF....FF...
After: FF...........FFF..................FF..................F....
}}}
It's a work in progress, but it's worth considering IMO.
Attaching a diff, and the full file (since the diff is going to be rather unreadable in some sections)"
16858.diff 16858 Awaiting Review Usage of HTTP_HOST in the administration reporter-feedback Administration 3.1 normal normal 2011-03-24T11:09:47Z "In some files like wp-admin/includes/class-wp-list-table.php (there are more files I think), some links are created by using the HTTP_HOST variable.
It's better to use the defined wordpress URL to create those links.
In our case, we have a wordpress running behind a Squid cache. When you check for HTTP_HOST you get the *real* HOST and not the one with the Squid server.
To bypass the problem, I added in the main config.php a line like this :
{{{
$_SERVER['HTTP_HOST'] = 'www.my-visible-http-host.com';
}}}
Without this setting and in our case, some links in the admin (next, previous page, re-ordering...) where pointing to the wrong server.
"
16226.2.diff 16226 Awaiting Review Attachment URL filenames are not urlencoded dev-feedback Upload 3.1 normal normal 2011-02-14T08:17:20Z "In looking at #16191, I discovered a related bug.
Upload a file called {{{a%22b.jpg}}}. The file will be stored on the filesystem as {{{a%22b.jpg}}}, but the resulting attachment URL will be http://example.com/wp-content/uploads/2011/01/a%22b.jpg, which will point to a file named {{{a""b.jpg}}}."
28633.8.diff 28633 Future Generate better random numbers needs-testing Security normal normal 2015-02-16T01:30:20Z Never used Trac/SVN at all, so I apologize if I'm doing this wrong. I want to submit what a github user would call a pull request. Although this is classified as security, it's not exactly a critical 0day vulnerability I found or anything.
31270.ut.diff 31270 Future Unexpected slugs for same-title different-parents term creation has-patch Taxonomy 4.1 normal normal 2015-02-09T03:42:46Z "When creating a new term which matches an existing terms name, it uses that slugs slug as the slug prefix, which can result in an unexpected term slug.
For example, take this:
{{{
Foo (slug: foo)
- Bar (slug: foo-bar)
}}}
If we now create a root level ""Bar"" term, it'll get a slug of {{{foo-bar-2}}}, when one would expect it to receive {{{bar}}} since no conflicting slug exists.
This is related directly to [28733] / #17689.
Unit test attached showing behaviour."
14477-41-broken-ut.2.diff 14477 Future get_pages with child_of only works with uninterrupted hierarchies needs-patch Query 3.0 normal high 2014-12-02T03:02:42Z "I have a page X with several children and grandchildren. Some of the grandchildren have a certain meta key and value. I now want to fetch all pages under page X that have this meta key. After reading the documentation of ''get_pages'', I expected this to work with a single call of ''get_pages''.
But if I use get_pages like this:
{{{
get_pages('child_of=X&meta_key=A&meta_value=B');
}}}
it returns no pages at all (hierarchical=0 has no effect). It seems that's because ''child_of'' triggers a call of ''get_page_children'' which only returns uninterrupted hierarchies. Since the query returns only some grandchildren and no direct descendants, the function fails. IMHO, that's a bug.
"
28722.2.diff 28722 Future Boost performance with ETag in load-scripts.php and load-styles.php has-patch Script Loader 4.0 normal normal 2014-07-13T08:25:23Z "Attach ''ETag'' header to the file output and check the ''HTTP_IF_NONE_MATCH'' request header before ''echo''.
The generated ETag based on the MD5 checksum of the combined file content.
'''Network Performance Comparison'''
Without ETag (after page reload): https://db.tt/TSWkm7Qj
With ETag (after page reload): https://db.tt/YB7CLesw
Saving: ca. 150 KB incoming data
''Note: wp_unslash() is not available there. filter_input works fine.''"
25738.2.diff 25738 Future WP_HTTP uses transports that incorrectly claim to support a request needs-patch HTTP API normal normal 2013-11-15T06:37:32Z "Following on from #25716
We now have 2 HTTP transports, and 2 types of requests that we need to support:
|| ||HTTP||HTTPS||
||cURL|| || ||
||PHP Streams|| || ||
If we break it down further based on known compatibility issues, we can end up with this:
|| ||HTTP GET||HTTPS GET||HTTP POST||HTTPS POST||
||cURL ''no SSL''||✓||✘||✓||✘||
||cURL w/ OpenSSL||✓||✓||✓||✓||
||cURL w/ GnuTLS||✓||~||✓||~||
||cURL 7.31.0 w/ OpenSSL||✓||✓||✓||✘||
||cURL 7.10.6 w/ any SSL||✓||~||✓||~||
||cURL + DNS timeout||✘||✘||✘||✘||
||PHP Streams ''no SSL''||✓||✘||✓||✘||
||PHP Streams w/ OpenSSL||✓||✓||✓||✓||
(✓ = should work, ✘ = doesn't work, ~ = known issues)
For background of cURL 7.31.0 and GnuTLS see #25716
For background of cURL 7.10.6 see #25751 - SSL subjectAltNames is not supported by 7.10.6 or earlier.
WP_HTTP currently
* Tries to use cURL first, Streams second
* Only uses cURL for HTTPS if it ''claims'' to support HTTPS, we have no check in place to verify it can make a SSL connection
* Doesn't fall over to a 2nd transport in event of error
* Doesn't disable a transport in event of continued troubles
I think there are a few things we can possibly do here:
1. Disable a transport after multiple failed requests (See #16870)
1. Add a parameter to try the other transport if available (and if that works, lock it to using that transport for the rest of that page load so we have less timeouts)
!#1 would be a win for most users who have issues with cURL and DNS lookup failures, and any sites which have plugins that make a bunch of external HTTP calls.
!#1 can also have false positives, for example, oEmbed calls to sites that are down could disable a sites ability to make requests, so we might want to limit it to *.wordpress.org requests as a way of saying ""This site SHOULD be working""
!#1 and !#2 might not play nicely though if !#2 was implemented, we might not have enough data to reliably trigger the blocking.
!#2 would mean that we could use that for WordPress.org API requests, which would cause any HTTPS connections that fail via cURL succeeding through Streams (if supported).
Since it's possible for a site to have cURL with broken SSL, and no OpenSSL installed, we would still need extra code to handle a HTTPS -> HTTP fallback in the update API's though (perhaps this would be good as a wrapper ""connect over SSL if possible, else, use HTTP)
We also probably don't want to re-try every HTTP request, which makes adding a parameter for it probably a better idea, the other option would be to simply detect certain cURL/streams error codes and re-try those.
potentially we wouldn't want it to re-try zip package downloads too"
25840.3.diff 25840 Future Feature Request: WP_ACCESSIBLE_HOSTS as option needs-testing HTTP API 3.7.1 normal normal 2013-11-08T02:36:05Z "Currently WP_ACCESSIBLE_HOSTS is defined as a constant. It would be great if this is a wordpress option (or something equivalent) so you can change it at runtime. If you have a multisite installation and need to add domains to the whitelist you must reload the whole installation to enable them. Writing a simple plugin for this is also not possible since constants can not be redefined.
My suggestion:
1) Store a site_option for mutlisites. This should contain a general whitelist for all blogs
2) Store a option per blog to contain additional whitelists for this single blog
3) Make it configurable via the admin interface (single textbox to enter the domains)
4) In the block_request function (https://github.com/WordPress/WordPress/blob/master/wp-includes/class-http.php#L507) the 2 options should be merged and handled like the constant
This way you could manage the whitelist at runtime.
What do you think about this?
Chris"
25692.layer.diff 25692 Future Update /info/ API endpoints needs-patch Upgrade/Install 3.7 normal normal 2013-10-28T04:16:18Z "The `/info/` API endpoints need to be updated to use JSON encoding.
Previously: #25311"
25252.diff 25252 Future Pin the WordPress.org SSL certificates needs-patch HTTP API 3.8 normal normal 2013-10-16T22:28:20Z "#25007 introduced full SSL support for the streams transport, but still leaves us open to having [http://www.comodo.com/Comodo-Fraud-Incident-2011-03-23.html a valid certificate posing as WordPress.org]. This is a huge issue with things like auto-upgrades, since we need to ensure that we're acting in a safe manner.
The way this type of issue has been handled is to use [https://www.owasp.org/index.php/Certificate_and_Public_Key_Pinning certificate pinning]. This has been in Chrome for Google-related properties since version 13 (with [https://src.chromium.org/viewvc/chrome/trunk/src/net/http/transport_security_state_static.json ever-expanding support]) and Firefox is [https://wiki.mozilla.org/Security/Features/CA_pinning_functionality moving towards implementing it].
In terms of how we achieve this, we can simply set the cacert path to the .org certificates locally.
One issue we might want to consider here is whether this is flexible enough. Certificates may (should) expire, and we don't want sites everywhere breaking because of this. I believe the best solution here is to make a long-lived certificate for .org and bundle that as the CA, with the real certificates being signed by that one."
22840.diff 22840 Future Uploading an existing plugin saves the zip in media library needs-patch Upgrade/Install 3.4.2 normal normal 2013-09-13T07:10:32Z "Action: Install the same plugin twice.
Expected behavior: Second time, plugin should fail and not install.
Actual Behavior: Install fails, but the plugin's .zip shows in the Media Library. (Shows in Site #1 on Multisite)
This ''is not'' a 3.5 regression, same things happens in 3.4.2"
23845.diff 23845 Future Install new theme via FTP failed needs-patch Filesystem API 3.5.1 normal normal 2013-09-06T05:28:22Z "New theme installation via FTP has failed when we specified custom FTP_BASE folder. If we try this theme installation , wordpress shows error message: ""Unable to locate WordPress theme directory"". This was because search_for_folder method do not respect FTP_BASE setting and allows to walking on parent directories. All solutions I found in google is ugly hacks who only mask the problem but does not resolved it
I attached patch example who resolve this problem. I hope is useful and will help to repair this bug."
15101.diff 15101 Future Update Message Reduces User Orientation reg. WordPress Version has-patch Upgrade/Install 2.5 normal normal 2013-08-21T06:38:13Z "This is a usability issue many customers are telling me: When there is a WordPress update message, the current version is not prominent any longer.
Normally the current version is displayed in the admin's footer. If there is a (very promintent ""on top"") update message, this version information get's hidden in footer as well.
The only place where a user can find the current version is in some dashboard widget. That location is hard to find. And that location is hard to describe on the phone, e.g. in support.
I suggest to restore the current version display in the footer, because a footer is very easy to find and to describe by phone.
Additionally the update message on top should display the current version number as well. Something Like There is a new version available, you're currently running (should be 65%-70% of the width in english text of a 1024 width screen (970 or so viewport size) to allow this to be translated w/o consuming too much of the screen real estate)."
20652.unit-tests.diff 20652 Future Install plugins with FTP upload, virtual subdomain, bad base dir? needs-patch Filesystem API 3.3.2 normal normal 2013-08-20T05:41:24Z "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
"
24635.diff 24635 Future update_user_caches() should support accepting a WP_User instance has-patch Users 3.0 normal normal 2013-06-24T08:20:30Z "At present update_user_caches($user) blindly stores the value from $user into the object cache.
Although core only ever passes the raw data from `wp_users` into this function, due to the naming of it, and the phpdoc, plugin devs may pass a WP_User instance to the function.
The result is that a WP_User instance is stored within the object cache rather than stdClass of a `wp_users` row as expected.
For most intents this causes little issue, the function and cache still work, so the developer will see no side effects.
But this has the cause that when that user's data is retrieved from the cache, the original WP_User object is restored -- including all meta keys that were stored in it, If one of those meta keys is a serialized object which calls a not-yet-loaded function, it can cause the request to fatal error. It's a pretty specific issue, but can simply be avoided by never storing a WP_User instance in the cache.
Attached patch simply tests for the data and acts appropriately. mostly untested."
22952.2.diff 22952 Future WP_HTTP can cause PHP Warnings during attempted decompression needs-testing HTTP API 3.3 normal normal 2012-12-15T07:53:57Z "{{{
WARNING: wp-includes/class-http.php:1656 - gzinflate(): data error
}}}
WP_Http_Encoding can cause PHP Warnings when it attempts to decompress data using gzinflate() which has been encoded in any way.
We currently work around this this in a few ways, but we still take a ""try it and see"" method instead of detecting the compressed contents signature and handling it appropriately.
Attached is a first-run patch at detecting Huffman coding, which is what we currently use `@gzinflate( substr( $gzData, 2 ) )` for (and hey, who doesn't like making magic numbers clearer?)
I have been running a similar patch on !WordPress.com and gathering data on how the myriad of different Web Servers out there respond, and so far this causes it to correctly identify the vast majority of responses.
It appears that we may also be attempting to decompress compressed files retrieved through WP_HTTP on some poorly configured servers, but this is something I haven't yet traced properly."
19781.diff 19781 Future All update processes should be within an iframe has-patch Upgrade/Install normal normal 2012-03-18T06:23:50Z "Currently some of the update processes run within iframes, others don't.
We should standardise on all within an iframe.
Running inside the iframe has the advantage that the footer of the page is loaded, and therefor, the Toolbar will load, rather than the page appearing half-loaded for certain upgrade/install processes.
Currently, Processes which run inside iframes are Bulk updates, Singular updates load directly.
~~We should also investigate a iframe overlay that contains a ""Working.. please wait"" graphic that clears once the content of the iframe starts loading, This should help ease the pain of not being sure if the update process has started on servers that force gzip (and as a result, provide no user feedback until the process is complete) - See #18525 and #18239 for examlples of that~~ see #19783"
18289.5.diff 18289 Future Direct link to plugin installation should have admin chrome needs-testing Upgrade/Install normal normal 2011-10-05T13:13:47Z "We should be able to provide a direct link to the page to install a plugin, based on the plugin's slug. This does it: wp-admin/plugin-install.php?tab=plugin-information&plugin=log-deprecated-notices. However, there's no admin chrome, no real indication which site you're on, and no name of the plugin.
If we're not loading that page inside an iframe request, it needs the admin around it, as well as a heading. Probably new styling too.
This would serve as a replacement for [http://coveredwebservices.com/wp-plugin-install/ Jaquith's bookmarklet], which broke in 3.2 (frame busting), as well as allow us to integrate a link on extend/plugins for plugin installation. Related, #16923, which is now closed."
testing-script.php 18738 Future Improving cron spawning and other non-blocking HTTP requests has-patch HTTP API normal high 2011-09-24T06:11:16Z "The order of preference for transport methods in the HTTP API is cURL, streams, fsockopen. However cURL and streams cannot perform non-blocking requests, but fsockopen can. Therefore, fsockopen should be the highest priority transport method for non-blocking HTTP requests.
Here's an example. I have a script at `http://ctftw.com/sleep.php` which sleeps for 5 seconds.
{{{
$start = microtime( true );
wp_remote_get( 'http://ctftw.com/sleep.php', array(
'blocking' => false
) );
$end = microtime( true );
var_dump( $end - $start );
}}}
When the cURL or streams transports are used, this request blocks the page for 5 seconds (the default request timeout is 5 seconds).
Let's disable the cURL and streams transports (leaving only fsockopen) and try again:
{{{
add_filter( 'use_curl_transport', '__return_false' );
add_filter( 'use_streams_transport', '__return_false' );
$start = microtime( true );
wp_remote_get( 'http://ctftw.com/sleep.php', array(
'blocking' => false
) );
$end = microtime( true );
var_dump( $end - $start );
}}}
This request does not block the page because fsockopen returns immediately after sending the request.
== Cron Spawning ==
This is a benefit to core because it improves the cron spawner (and can potentially fix #8923). The cron spawner uses a timeout of 0.01 seconds and a non-blocking request, but actually takes longer than 0.01 seconds.
Example:
{{{
$cron_url = get_option( 'siteurl' ) . '/wp-cron.php?doing_wp_cron';
$start = microtime( true );
wp_remote_post( $cron_url, array(
'timeout' => 0.01,
'blocking' => false
) );
$end = microtime( true );
var_dump( $end - $start );
}}}
This request takes around 1.1 seconds on the three servers I've tested it on.
Let's disable cURL and streams again (leaving only fsockopen) and see what we get:
{{{
add_filter( 'use_curl_transport', '__return_false' );
add_filter( 'use_streams_transport', '__return_false' );
$cron_url = get_option( 'siteurl' ) . '/wp-cron.php?doing_wp_cron';
$start = microtime( true );
wp_remote_post( $cron_url, array(
'timeout' => 0.01,
'blocking' => false
) );
$end = microtime( true );
var_dump( $end - $start );
}}}
On each of my three servers I see a time of around 0.001 seconds.
We can therefore improve the cron spawner by setting fsockopen as the preferred transport method for non-blocking HTTP requests.
In an attempt to address #8923, we can change the cron request timeout to 1 second. If fsockopen is used, the request is lightning fast at ~0.001 seconds. If it's not available and the HTTP API falls back to cURL or streams then it takes ~1.1 second, which is the same time it takes currently. (Hopefully that makes sense.)
Patch coming up for those who want to test it."
17552.patch 17552 Future Plugin editor incorrectly calls some files inactive. has-patch Plugins 3.1 normal normal 2011-08-12T14:13:07Z "The plugin editor has a helpful bit of text at the top to specify if the current file is active on the site or not; This works fine in most cases, however, I've noticed that it only works for the ''plugin file itself''.
Ie. Editing akismet/akismet.php will specify it's active, Editing akismet/admin.php will show as inactive.
This is due to the use of is_plugin_active() from memory. The solution to this would be to run is_plugin_active() on {{{$_GET['plugin']}}} instead of the file being edited.
{{{$_GET['plugin']}}} has it's own bug however, It's set to whichever file was edited before you loaded the current file (when you switch between files in a plugin that is), which in some cases will be correct, in many others when you're editing multiple files, It'll be incorrect."
18386.patch 18386 Future "Bug in custom query when ""Front page displays"": ""A static page""" dev-feedback Query 3.2.1 normal normal 2011-08-12T11:20:45Z "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:
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."
warning.jpg 16216 Future Hide core updater if running an svn checkout has-patch Upgrade/Install normal normal 2011-04-19T05:29:35Z The logic with this patch is if you are running an svn checkout, do not display the core updater code and instead display a reminder.
16979.diff 16979 Future Extra hooks needed in comment process dev-feedback Comments normal normal 2011-04-16T03:46:36Z "I'm running into a few commenting issues whilst building a plugin with a custom post type..
* Duplicate comment check's cannot be bypassed
* Empty comments are not allowed (In this case, the comment body is empty whilst a set of custom fields acting as metadata are set, meaning, the plugin wants to accept that comment)
* being able to override the wp_die() in the commenting process would be useful (Currently: Duplicate comments, User not logged in, and not all fields filled in will cause this)
One potential solution would be to move [http://core.trac.wordpress.org/browser/trunk/wp-comments-post.php#L55 lines 55-84] from `wp-comments-post.php` to functions hooked to `preprocess_comment`"
16156.diff 16156 Future update-core is oblivious to api.wp.org being unreachable dev-feedback Upgrade/Install normal normal 2011-04-04T07:12:56Z "A server running 3.0.4 had trouble reaching *.wordpress.org for some unknown reason. (This wasn't during the brief api.wp.org outage, and it worked otherwise.)
Problem is, update-core was completely oblivious to this. It's even worse when running 3.1, because the 'Check Again' button will refresh the page and tell you we last checked for updates *just now*.
Try Again or Check Again should reflect that the API is unreachable when this can be determined. Claiming that we checked for updates is also really lame, so we should see if the transient tells us how long it's been since the last one.
Side note, the plugin install et al. HTTP error messages are rather cryptic, and we should also make those more user friendly."
10884.diff 10884 Future Available plugin update count disappears after updating plugin dev-feedback Upgrade/Install 2.8.4 normal normal 2011-04-03T10:48:06Z "When there are any available plugin updates, WP displays number of them next to ""Plugins"" item in menu. However when you have more than one update available and update one plugin, it disappears.
Steps to reproduce:[[BR]]
- make sure you have more than one plugin with update available (WP should count of them in menu);[[BR]]
- go to the Plugin page and click on Autoupdate link for plugin;[[BR]]
- when update page will load completely, click on provided link to return to plugin list.
Expected result: WP displays new number of available updates next to Plugins menu.[[BR]]
Actual result: nothing is displayed.
Note: I tested this for inactive plugins only."
14401.diff 14401 Future Unable to locate WordPress Content directory (wp-content). needs-patch Filesystem API 3.0 normal normal 2011-03-22T00:37:52Z "Hi, I encounter this message on one server during plugin install: ""Unable to locate WordPress Content directory (wp-content).""
PHP Version 5.2.0-8+etch1
Another info from Core Control plugin:
Direct Not Available
SSH2 Not Available
PHP FTP Extension Available
PHP FTP Sockets Available
ABSPATH: /home/www/domain.eu/subdomains/www/
WP_CONTENT_DIR /home/www/domain.eu/subdomains/www/wp-content
WP_PLUGIN_DIR /home/www/domain.eu/subdomains/www/wp-content/plugins
DOCUMENT_ROOT (from phpinfo) /home/www/domain.eu/subdomains/www
I tried some hacks in wp-config.php, but I was not successfull.
When I tried ftpsockets, following error appears:
Warning: socket_last_error() expects parameter 1 to be resource, null given in /home/www/domain.eu/subdomains/www/wp-admin/includes/class-ftp-sockets.php on line 59
When I tried direct, following error appears:
Downloading install package from http://downloads.wordpress.org/plugin/wp-memory-usage.zip…
Unpacking the package
Could not create directory. /home/www/domain.eu/subdomains/www/wp-content/upgrade/wp-memory-usage.tmp"
16895.diff 16895 Future wp_list_pluck cannot be used with arrays of references dev-feedback General 3.1 normal normal 2011-03-19T11:49:26Z "Example code:
{{{
$one = array('num' => 1);
$two = array('num' => 2);
$input = array( &$one, &$two );
$nums = wp_list_pluck($input, 'num');
var_dump($nums, $input);
}}}
Example output:
{{{
array
0 => &int 1
1 => &int 2
array
0 => &int 1
1 => &int 2
}}}
Expected output:
{{{
array
0 => int 1
1 => int 2
array
0 => &
array
'num' => int 1
1 => &
array
'num' => int 2
}}}
This is caused by wp_list_pluck using the same variable name for the input array, and then overwriting it for the return.
One such real life example, is $wp_query->comments
See patch"
16282.diff 16282 Future PHP catchable error with get_term_link and WP3.1RC2 has-patch Taxonomy 3.1 normal normal 2011-01-24T21:37:22Z "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"
15949.diff 15949 Future WP 3.0.x comments popup on pages returning 404 [including posible solution] has-patch Query 3.0 normal normal 2010-12-26T23:30:48Z "comments-popup does not work on pages (but still working on blog entries) since the 3.0.x upgrade.
i confirm bug and sollution on both: my own theme and on default them after adding comments_popup_link and comments_popup_script functions.
after a long time looking for a solution i found that the new ""handle_404"" method in class WP (wp-includes/classes.php line 475) is the responsable, substituing this method with an older one from wp 2.x brunch solves the problem.
looks like the new method ""think"" that there is no content when the index file is called with comments_popup parameter on a page id, so it returns a 404 status, as said the old one solves the problem.
"
13989.diff 13989 Future Recent Comments widget optimization needs-patch Widgets 3.0 normal normal 2010-06-19T06:31:45Z "Currently when permalinks are enabled, the recent comments widget will call get_post() on each parent post to retrieve its permalink.
In the event that the posts the recent comments are on are not in the current query (for example, posts on old posts, or if we're currently on a singular view), then get_post() will perform a SQL query to load the postdata.
The attached patch introduces a {{{cache_posts($post_ids, $term_cache, $postmeta_cache);}}} function to mass load/cache a set of posts through the usage of WP_Query
The function is smart enough not to query for posts which are already in the Object cache (ie. If the comments are on the current page, it'll skip, or if its in a memory cache)
An example of the SQL query generated by this query:
{{{
SELECT wp_posts . *
FROM wp_posts
WHERE 1 =1
AND wp_posts.ID IN ( 95, 98, 106 )
AND wp_posts.post_type IN ('post', 'page', 'attachment', 'wiki', 'note', 'odd')
AND (wp_posts.post_status <> 'trash' AND wp_posts.post_status <> 'auto-draft')
}}}
Explain'd:
{{{
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE wp_posts range PRIMARY,type_status_date PRIMARY 8 NULL 3 Using where
}}}"
12601.2.diff 13041 Future Canonical redirection will redirect a non-exitant page to a post. needs-patch Canonical 3.0 normal normal 2010-04-18T06:15:14Z "Following on from #12601
Canonical redirection will kick in for http://localhost/wordpress-commit/apage/something and redirect it to http://localhost/wordpress-commit/2010/02/13/something-else/
#12601 limited redirect_guess_404_permalink() to only searching in the same post_type if one was provided, for posts and pages however, which are builtin, these vars are not set.
I'm attaching a patch which will prevent a Page -> Post redirection, but not the other way around. - this patch was originally added to the other ticket."
12456.diff 12456 Future Canonical URL redirect issue with post_id/postname permalink structure tested Canonical 2.9.2 normal normal 2010-03-05T12:01:27Z "The issue:
Using /%post_id%/%postname%/ as permalink structure,
Most canonical redirects work fine, except:
domain.com/post_id/ brings you to the post but does not redirect to the canonical domain.com/post_id/postname/
Additional info:
The above permalink structure conforms to best practice as described in the codex:
http://codex.wordpress.org/Using_Permalinks#Structure_Tags
Therefore I figured this was a bug, given the attention given to redirecting to the canonical url ""So to avoid confusing search engines and to consolidate your rankings for your content, there should only be one URL for a resource.""
http://markjaquith.wordpress.com/2007/09/25/wordpress-23-canonical-urls/
"
wp-ajax.php 12400 Future Add a wp_loaded hook, an ob_start hook, and an front end ajax hook dev-feedback Bootstrap/Load 3.0 normal normal 2010-02-28T03:51:59Z "Requests for some kind of wp_loaded hook have crept up here and there in trac over the years.
Typically, the requester is looking into doing front-end ajax requests and the like. There are other use cases, such as wanting to catch specific URIs -- e.g. a trailing /print/ to the url, which the permalink API is incapable of catching.
They all got rejected on grounds that there is the init hook that can be used just as well for ajax. Or the template_redirect hook in place of an ob_start hook. The list goes on.
When you want WP and plugins to be loaded '''and''' fully initialized, instantiated and ready to go, setting a priority to obscene levels on the init hook works (I typically use 1000000)... but it always feels like you're working around a crippled API.
Starting output buffers on template_redirect with a priority -1000000 feels equally clunky.
Then, there is the front-end ajax. Yes, admin-ajax.php can be used unauthenticated... But the fact of the matter is, you can end up with SSL turned on when it's not useful, and the lack of an wp-ajax.php file makes many a plugin dev wonder where in the bloody hell he should catch his own requests.
It would be sweet if this all got fixed in WP 3.0.
The argument that goes ""a hook already exists"" seems extremely invalid to me. There are many places in WP where two hooks (and oftentimes many more) can be used to achieve the same result. Think wp_headers and send_headers, for instance. What they have in common is some kind of before/after flow, which init and template_redirect are currently lacking.
One could argue that parse_request is nearby init, and that wp is nearby template_redirect, so they'd be good enough. But the first of these parses expensive regular expressions before firing, and both are only known to WP junkies.
Suggested hooks for WP 3.0:
- a wp-ajax.php file built similarly to admin-ajax.php.
- an wp_loaded hook at the very end of wp-settings.php, with a commentary that tells plugin authors that init should be used to instantiate, wp_loaded should be used to act once everything is instantiated, and that wp-ajax.php has hooks that are specific to ajax requests.
- an ob_start (or pre_load_template, or whatever...) hook at the very beginning of template-loader.php, with a commentary that tells plugin authors that the new hook should be used to instantiate such as output buffering once WP is fully loaded, while the second is traditionally used to pick an arbitrary template."
10831.diff 10831 Future Autoupgrade: Synchronous FTP client fails while plugin upgrade/installation (on some systems) needs-patch Filesystem API 2.8.4 normal normal 2010-01-17T03:08:02Z "Decription here
http://wordpress.org/support/topic/288093
Apache/2.2.13 (Unix) DAV/2 mod_ssl/2.2.13 OpenSSL/0.9.8k configured
PHP 5.2.10 with Suhosin-Patch 0.9.7 (cli) (built: Jul 14 2009 11:56:54)
pure-ftpd-1.0.22-1
I solved by changing some lines of code in class-ftp-sockets.php
(_exec and _readmsg)
Below the patch:
http://darkman.it/x/class-ftp-sockets.patch
"
11623.diff 11623 Future review options list and update sanitize_option() needs-patch Security 2.9 normal normal 2009-12-26T01:24:37Z "A lot of options have been added since 2.0.5, and as a result, not all of them have been added to {{{sanitize_option()}}}
Ideally, Options which are to be (int) or absint() should have a filter applied to them here.
Attached patch is for the first option thats brought this up, 'start_of_week' which is tested to be int in some function uses, ignored elsewhere.
I've set this to security as its preventive security.."
test.php 6778 Future Detect when the config will cause infinite loop dev-feedback Permalinks 2.5 normal normal 2009-08-16T12:00:19Z "Behavior:
If you put in http://www.domain.com in the ""Wordpress Address"" setting, then Wordpress will automatically do a redirect from http://domain.com to http://www.domain.com. Many hosting packages allow the user to deal with www and non-www versions of their domain. This will cause an infinite redirect loop if, for example, the ""Wordpress Address"" is set to http://www.domain.com and the hosting setting is set remove the www from the domain address-- to redirect http://www.domain.com to http://domain.com.
Expected behavior:
When setting the ""Wordpress Address"" setting, it should detect if the canocical code will cause an infinite redirect loop and warn/correct the mistake"
10535.2.diff 10535 Future _wp_filter_build_unique_id issues with the first time a filter is hooked by a class has-patch Plugins 2.9 normal normal 2009-08-02T13:26:09Z "Ref #8723
The first time _wp_filter_build_unique_id is used to generate an ID the ID returned is different to the second time it is called. This presents a problem if the first ID is used when adding a filter which then needs to be removed later in the app flow... as the IDs don't match the filter is unremovable.
One workaround proposed is to set a wp_filter_id property before add the filter, and this will cause _wp_filter_build_unique_id to bypass the problem code and effectively forces the ""unique"" ID which is generated... this workaround feels unpoetic. ;)"
7795.diff 7795 Future Activate and Deactivate Theme hooks needs-patch Themes 2.7 normal normal 2008-12-18T12:50:03Z Currently, there is no standard way of checking whether of theme is activated, deactivated and uninstalled. Plugins have this capability and themes should also have the same to ensure that both share similar functionality.
combine.php 3372 Future Consolidated JavaScript/CSS Plugin API dev-feedback Script Loader 2.1 normal lowest 2008-09-20T00:47:43Z "WordPress plugins are great, they really are. One problem with them is they often include their own styles and scripts. The problem here is that several plugins with useful features mean a browser needs to download 10+ javascripts and stylesheets. This isn't good for page load. It's awful. See:
http://www.die.net/musings/page_load_time/
My suggestion would be an API that allows all plugin/css to be included in 1 PHP generated CSS and Javascript. This would drastically consolidate requests. For performance reasons it should ideally be cached so that it's only regenerated when a plugin is loaded/reloaded.
This is becoming a bigger issue as plugins become more common and useful. I hope a solution is found that gives plugin authors the freedom they need, and blog owners the performance they want, without having to sacrifice features. I think channeling all the requests into 1 JS and 1 CSS file would achieve that. They could use a numerical ranking system to calculate position in the file (to avoid conflicts) similar to how (iirc) filter work."
32774.diff 32774 Awaiting Review Improve WP_Filesystem::dirlist() format consistency needs-patch Filesystem API minor normal 2015-06-24T07:06:16Z "At present the return values of dirlist() between the various methods are scattered between several different formats
||Field||Direct||FTP Ext||FTP Sockets||SSH2||
||name||Yes||Yes||Yes||Yes||
||perms||Yes||Yes||Yes||Yes||
||permsn||Yes||Yes||Yes||Yes||
||number||`false`||Yes||Yes||`false`||
||owner||Yes||Yes||Yes||Yes||
||group||Yes||Yes||Yes||Yes||
||size||Yes||Yes||Yes or `

`||Yes||
||lastmodunix||Unix Timestamp||No||No||Unix Timestamp||
||lastmod||`Nov 15`||No||No||`Nov 15`||
||time||`02:12:48`||Unix Timestamp||Unix Timestamp||`02:12:48`||
||year||No||Maybe||Maybe||No||
||month||No||`Nov`||`Nov`||No||
||day||No||`15`||`15`||No||
||hour||No||`02`||`02`||No||
||minute||No||`12`||`12`||No||
||type||`d` or `f`||`d`, `f`, or `l`||`d`, `f`, or `l`||`d` or `f`||
||isdir||No||Yes||Yes||No||
||islink||No||Yes||Yes||No||
If the FTP Server was Windows, it'd complicate it further by not returning certain fields, using different data in them, or getting confused and not returning any data.
The attached patch boils it down to a consistent result of `[ 'filename.ext' => [...], ...]` with the nested arrays of:
||Field||Value||
||name||Filename||
||time||Unix Timestamp of last modified||
||size||File size or false for Directories||
||type||`d`, `f`, or `l` for Directory, File, or Link respectively||
||perms||A formatted human-readable `drwxr-xr-x`||
||permsn||A octal as string `'0755'` for Back-compat purposes||
||owner||Owner ID or name||
||group||Group ID or name||
||files||If it's a recursive directory lookup, a nested array of files||
A number of these are only got back-compat or to match the FTP output - most of these fields are not used by WordPress at all - Specifically `group`, `owner`, `perms`, `permsn`, and `time` are ignored 100% by WordPress (along with a lot of the methods)
Changing this has some back-compat issues for any plugins doing anything special with the fields - however they've had to work around the fields returning random content already, so this shouldn't be a huge issue (or they were already broken)"
10786.diff 10786 Future Implementation of %my_taxonomy% in permastructs is incomplete dev-feedback Permalinks 2.9 minor normal 2009-09-18T01:57:39Z "The `register_taxonomy()` function includes a call to `add_rewrite_tag()` which should allow for a site's permastruct to include a %my_taxonomy% tag just like you can include a %category% tag or a %tag% tag, however this implementation is incomplete and doesn't work.
Example:
`register_taxonomy('genre','post');`
should allow you to create a permastruct (from the Settings->Permalinks screen) which includes %genre% in it.
The problem is that `get_permalink()` doesn't check for custom taxonomies and the replacement of %genre% with your post's genre in the permalink doesn't happen.
Patch upcoming."