_filename ticket Milestone type summary workflow component version severity priority modified _description
42352.3.diff 42352 Future new enhancement Support use of native MySQLi prepared queries needs-patch Database normal normal 2017-10-27T09:28:42Z "When we added `$wpdb->prepare()` back in WordPress 2.3, we were forced to roll our own MySQL Prepared queries as the MySQL extension didn't support it.
While the MySQL extension still doesn't, the majority of WordPress sites are likely using the newer MySQLi engine (by default, enabled for PHP 5.5+ which accounts for 70~80% of sites). That makes now a good time to start investigating the potential implementation and usage of native prepared queries in the future.
Attached is a first-draft of implementing native prepared queries into WPDB, it has no fallbacks for MySQL at present, but it would be possible to force support in for it using a ""simple"" SQL parser.
Unfortunately I expect that this draft is incompatible with many DB drop-ins, which is okay, this is only a draft and proof-of-concept.
I'll attach some examples of how this first draft could be used in a comment below."
40927.diff 40927 Future new defect (bug) Passing a float as the position in add_menu_page can override other menu items has-patch Administration 4.8 normal normal 2017-06-06T01:20:23Z "If you pass a float value for the `$position` argument of `add_menu_page`, PHP will convert it to an integer which overrides any other menu items with that position.
Per the [http://php.net/manual/en/language.types.array.php PHP docs]...
>Floats are also cast to integers, which means that the fractional part will be truncated. E.g. the key 8.7 will actually be stored under 8.
You can see this happening with the following snippet. The Test 2 menu item will show but Test 1 will not.
{{{#!php
run( array(
'package' => $r->package,
'destination' => WP_PLUGIN_DIR,
'clear_destination' => true,
'clear_working' => true,
'is_multi' => true,
'hook_extra' => array(
'plugin' => $plugin
)
) );
$results[$plugin] = $this->result;
}}}
Notice how the result is stored in the `$result` variable yet the `$results` variable, which is used as the return value, stores the `$this->result` variable. While the `$this->result` variable does contain some data, it's not very relevant as a return value for these functions. This issue causes a loss of most, if not all error feedback (I have yet to test every possible combination of result possibilities) and fails to provide any useful success condition responses. In most of my test cases, this issue results in each package having a response value of `null`.
This same issue can be found in the Language_Pack_Upgrader and Theme_Upgrader classes.
My solution is to simply change `$this->result` to `$result` as found in the supplied patch and as shown below:
{{{#!php
$results[$plugin] = $result;
}}}"
33053.diff 33053 Future new defect (bug) 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."
version-421-update-to-422.png 15101 Future new enhancement Update Message Reduces User Orientation reg. WordPress Version has-patch Upgrade/Install 2.5 normal normal 2015-06-16T04:57:30Z "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)."
31270.ut.diff 31270 Future assigned defect (bug) 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.diff 14477 Future reopened enhancement get_pages with child_of only works with uninterrupted hierarchies needs-patch Query 3.0 normal high 2014-11-27T02:49:41Z "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.
"
25840.3.diff 25840 Future new enhancement 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 new enhancement Update /info/ API endpoints has-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"
22840.diff 22840 Future new defect (bug) 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 new defect (bug) 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."
14401.unit-tests.diff 14401 Future reopened defect (bug) Unable to locate WordPress Content directory (wp-content). needs-patch Filesystem API 3.0 normal normal 2013-08-20T07:34:12Z "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"
info.htm 20652 Future reopened defect (bug) Install plugins with FTP upload, virtual subdomain, bad base dir? needs-patch Filesystem API 3.3 normal normal 2012-05-10T12:47:45Z "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
"
18289.6.diff 18289 Future reviewing task (blessed) Direct link to plugin installation should have admin chrome needs-testing Upgrade/Install normal normal 2011-10-05T13:52:30Z "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."
WP_Request.php 18322 Future new defect (bug) The Road to Magic Quotes Sanity dev-feedback Bootstrap/Load 3.2.1 normal 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.
warning.jpg 16216 Future new enhancement 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.
16156.diff 16156 Future new defect (bug) 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."
12601.2.diff 13041 Future reviewing defect (bug) Canonical redirection will redirect a non-exitant page to a post. has-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."
11623.diff 11623 Future accepted defect (bug) 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.."
10786.diff 10786 Future assigned defect (bug) 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."
test.php 6778 Future reopened enhancement 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.diff 10535 Future reopened defect (bug) _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-02T12:55:46Z "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 assigned enhancement 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.
41502.diff 41502 Awaiting Review new defect (bug) _wp_expand_nav_menu_post_data() corrupts multiple select (array value) has-patch Menus 4.9 normal normal 2017-12-13T09:47:18Z "Hi guys.
Elliot here - ACF developer.
I've recently added custom fields to the WP menu and WP menu item forms.
In doing so, i have discovered that the `_wp_expand_nav_menu_post_data()` function (called in wp-admin/nav-menus.php on line 56) is corrupting some array $_POST values.
The issue is caused with inputs using a name like so:
`my_field[]`
`my_field[]`
Please note that there is no issue when a key is defined like so:
`my_field[0]`
`my_field[1]`
There are many cases where a developer would not define the 'keys' of an 'array type' input name. Think of a multiple select element. The element accepts only one name attribute and it must be defined like so `my_field[]`.
- Also, checkbox / radio fields are commonly rendered using the same naming style.
Is it possible to request some extra logic within the `_wp_expand_nav_menu_post_data()` function that allows for this?
I suspect the issue is caused on line 1125 of the 'wp-admin/includes/nav-menu.php' file where the $_POST value is modified:
`$new_post_data[ $array_bits[ $i ] ] = wp_slash( $post_input_data->value );`
Thanks
Elliot"
38931.diff 38931 Awaiting Review new defect (bug) `update_option()` race condition with non-autoloaded options has-patch Options, Meta APIs 3.7 normal normal 2016-11-24T13:32:41Z "Starting back in [25664] there's a race condition with object caches where `get_option()` will return a value, but `update_option()` will refuse to update it.
This is kind-of-related to `alloptions`, but affects non-autoloaded options (which are not in `alloptions`, but in their own cache).
Consider the following scenario:
{{{
Process 1: Fetch option_a. Fills local cache.
Process 2: Update option_a.
Process 1: Delete option_a.
Process 2: Update DB.
Process 1: Delete from DB. Delete from remote cache.
Process 2: Update remote cache.
...
Process 5: Fetch option_a. Fills local cache from remote cache.
Process 5: Update option_a. FAIL. DB doesn't have option. abort. cache not updated.
...
(repeat process 5 above many times)
Process 10: Get option_a (Still the value that Process 2 set in cache, even though it's not in the DB)
Process 10: Update option_a (Doing the same as Process 5 now). FAIL.
}}}
Seems very racey and unlikely, but I've seen it happen on WordPress.org at least twice in the last few weeks when we update Jetpack (which makes heavy usage of the options table, and is loaded on most WordPress.org requests).
When it happens, `get_option()` will continue to return a stale value from the cache that no longer exists in the DB and `update_option()` will fail to update the option as long as it exists in cache.
If a plugin is performing an operation to update the stale option often, it can cause a huge load spike on the database server of never-ending failing `UPDATE` queries.
The only way to 'fix' it is to create the DB row manually, or flush the object cache key.
The patch attached attempts to perform an `add_option()` in the case of the `update_option()` DB query failing.
This isn't exactly a new behaviour for options - `add_option()` will effectively perform an `update_option()` in the event the option you're trying to add already exists (through it using `INSERT .. ON DUPLICATE KEY UPDATE..`), doing it in reverse doesn't seem that out of the question."
38243.diff 38243 Awaiting Review new defect (bug) Attempting to create a term with invalid UTF8 characters creates a blank term has-patch Taxonomy normal normal 2016-10-06T13:53:23Z "Attempting to insert a term which contains invalid UTF8 characters will incorrectly create a term in the database with a blank name & slug. This happens as we check that the term name & slug is provided, but fail to check after sanitizing the term.
In the scenario that I've run into, something similar to this happens:
{{{
$term_name = urldecode( ""360%BF"" ); // Invalid UTF8 character
wp_insert_term( $term_name, 'my_taxonomy' );
}}}
What this causes is
* the checks on `$name` to pass
* it then hits `sanitize_term()` and after passing through `sanitize_text_field()` and then `wp_check_invalid_utf8()` the `name` field of the term is set to an empty string.
* `wp_insert_term()` then takes this empty name and creates an equally empty slug from it.
* `wp_insert_term()` then calls `get_terms( array( 'name' => '' ) )` and needlessly & badly loads up all 60,000 terms into memory of the custom taxonomy
* `wp_insert_term()` then see's an empty slug and ultimates settles on a setting the slug to the numeric ID of the term somehow
* `wp_insert_term()` finally inserts a term with a numeric slug and empty `name` field
I think at a minimum, we should verify that the term name is still valid after term sanitisation. See patch for that."
36426.diff 36426 Awaiting Review new enhancement WP Admin memory limit not increasing to base limit by default has-patch Administration 4.6 normal normal 2016-08-19T04:45:01Z "We have 2 constants that can be set in wp-config.php (and by using filters, afaik), for example:
{{{#!php
define( 'WP_MEMORY_LIMIT', '512M' ); // increases WP base (front-end) limit
define( 'WP_MAX_MEMORY_LIMIT', '512M'); // increases WP admin (back-end) limit
}}}
The former isn't really known, which you can Google to find out. People usually only use the first constant.
If the 2nd constant (WP_MAX_MEMORY_LIMIT) is not set, it defaults to 256M. WP_MEMORY_LIMIT can be higher than that though, so we could safely increase WP_MAX_MEMORY_LIMIT to match WP_MEMORY_LIMIT if WP_MEMORY_LIMIT is higher and WP_MAX_MEMORY_LIMIT is not set manually to a lower (than WP_MEMORY_LIMIT) value.
What I mean in coding terms:
{{{
if(!isset(WP_MAX_MEMORY_LIMIT) && isset(WP_MEMORY_LIMIT)){
if(WP_MEMORY_LIMIT>DEFAULT_WP_MAX_MEMORY_LIMIT){
//NOTE to the line above: this requires parsing the actual value in these constants as the strings can be like: 512M, 1G etc.; the DEFAULT_WP_MAX_MEMORY_LIMIT is a thing I came up with, currently the default admin memory limit is 256M
define( 'WP_MAX_MEMORY_LIMIT', WP_MEMORY_LIMIT);
}
}
}}}
All these values can be checked with the Bulletproof Security plugin, under BPS Security -> System Info.
Side note: imho WP_MAX_MEMORY_LIMIT should be renamed to something like WP_ADMIN_MEMORY_LIMIT, but that's another issue.
"
35983.diff 35983 Awaiting Review new enhancement "Better support for ""singular"" endpoints" has-patch Rewrite Rules normal normal 2016-02-28T04:47:54Z "WP_Rewrite endpoints are currently geared towards endpoints that capture content after it, for example, `/feed/FEED_TYPE/`.
Quite often we instead want to create an endpoint which is instead `/embed/` or `/faq/` we don't need to capture an optional bit of data after it.
Currently endpoints can operate in either mode, if you specify and endpoint of `test-endpoint` then both `/endpoint-name/` and `/endpoint-name/data-passed/` will work.
The problem comes when testing for the existence of that endpoint in the query.
An endpoint which passes data is easy to check `if ( get_query_var('endpoint-name') )`, an endpoint which doesn't - not so easy `global $wp_query; if ( isset( $wp_query->query_var['single-endpoint'] ) )`.
Something that would be easier, and nicer for developers using the rewrite endpoint is to instead match the endpoint name itself:
Currently the rewrite rule would look like this:
{{{
([^/]+)/endpoint-name(/(.*))?/?$ => index.php?name=$1&endpoint-name=$3
}}}
What would be great, is if we can do instead:
{{{
add_endpoint( 'single-endpoint', ... );
([^/]+)/(single-endpoint)/?$ => index.php?name=$1&single-endpoint=$2
}}}
Which if used in conjunction with `add_endpoint()`'s 3rd parameter allowing us to specify a custom query_var:
{{{
add_endpoint( 'endpoint-name', ..., 'special_query' );
add_endpoint( 'another-endpoint-name', ..., 'special_query' );
Rules:
([^/]+)/(endpoint-name)/?$ => index.php?name=$1&special_query=$2
([^/]+)/(another-endpoint-name)/?$ => index.php?name=$1&special_query=$2
}}}
this would then allow us to use `if ( get_query_var( 'special_query' ) )` or `if ( get_query_var( 'single-endpoint' ) ) ` in the case of the first example.
Attached is an implementation which upgrades the 3rd parameter (`$query_var`) to an array to support this. It's a super-rough patch, but appears to work. Does anyone else feel that this is worthwhile supporting?"
32774.diff 32774 Awaiting Review new defect (bug) 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)"
5vPGCCt7.diff 32452 Awaiting Review new defect (bug) 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 reviewing defect (bug) SimplePie error with fetch_feed() has-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."
Screen Shot 2015-02-24 at 11.22.25 am.png 26886 Awaiting Review reopened defect (bug) wp_enqueue_script doesn't load all scripts reporter-feedback Script Loader 3.8 normal normal 2015-02-24T00:23:33Z "trying to load scripts with wp_enqueue_script produces the following output:
{{{
wp-admin/load-scripts.php?c=1&load%5B%5D=hoverIntent,common,admin-bar,svg-painter,heartbeat,jquery-ui-datep&load%5B%5D=icker,jquery-ui-resizable,..,jquery-ui-to&load%5B%5D=oltip&ver=3.8'>
}}}
sometimes where this characters inserted:
'''&load%5B%5D='''
e.g.
'''jquery-ui-to&load%5B%5D=oltip'''
instead ''jquery-ui-tooltip''
Please see also this support thread
link:[http://wordpress.org/support/topic/widgets-not-drag-or-drop-after-update-to-38?replies=3#post-5128942]
"
26802.diff 26802 Awaiting Review accepted defect (bug) 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.
"
25741.diff 25741 Awaiting Review new defect (bug) Broken WP_Filesystem methods needs-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."
argus.php 16808 Awaiting Review reopened defect (bug) 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 new defect (bug) wp_ob_end_flush_all() tries to destroy non-destroyable output buffers has-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."
canonical.php 18385 Awaiting Review new enhancement "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:05:57Z "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 reviewing defect (bug) Usage of HTTP_HOST in the administration has-patch 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.
"
4280.diff 4280 Awaiting Review reopened feature request Allow to constrain widgets being displayed on certain page types only needs-patch Widgets 2.2 minor low 2008-06-25T02:26:37Z "The only real added value of the Sidebar Modules (SBM) plugin right now is the possibility to customize, which widgets are to be displayed on which pages (setting at Sidebar Modules//Module's Options/Display On).
With this you are able to highly customize your sidebars even down to a single post's page.
It might also make sense to define sidebars per category a post is in.
However, it makes the most sense to have different sidebars on the Homepage, different static pages and posts pages."
42811.diff 42811 5.0 new defect (bug) Run the PHP 5.2 Travis job with the MySQL Extension commit Build/Test Tools normal normal 2017-12-06T07:57:54Z "I just noticed that the PHP 5.2 job is running with MySQLi (which I didn't even realise was possible).
That ultimately means we have no automated testing which is testing the `mysql_*` functions in `$wpdb` which is used for PHP 5.2~5.4 by default.
The attached patch uses `WP_USE_EXT_MYSQL` to force it to use the MySQL extension for the PHP 5.2 job, I've tested this on [https://travis-ci.org/dd32/wordpress-develop/jobs/312272686 my own travis account] and it passes as expected, with the only change being an additional skipped test (which requires mysqli)."
42486.diff 42486 4.9.5 new defect (bug) The Tools screen is blank for users who cannot manage categories or tags 2nd-opinion Administration 4.9 normal normal 2017-11-24T08:01:30Z "Since Press This was removed in #41689, the Tools screen is only composed of the Categories and Tags Converter.
For users who can't manage categories or tags (Authors and Contributors), the Tools screen is now completely empty. Subscribers currently don't see the Tools admin menu item.
The Tools admin menu item should be removed if there's nothing to display on it."