__group__,ticket,summary,owner,_component,_version,priority,severity,milestone,type,_status,workflow,_created,modified,_description,_reporter
Tickets Awaiting Review,40195,No provision to set paths for sftp (ssh2),,Filesystem API,4.7.2,normal,normal,Awaiting Review,defect (bug),new,,2017-03-18T13:36:00Z,2017-03-18T13:36:00Z,"I have a server which has different paths for the web server verses when accessed via sftp and consequently updates fail with ""Unable to locate WordPress content directory (wp-content).""
According to this page [https://codex.wordpress.org/Editing%20wp-config.php#Enabling_SSH_Upgrade_Access] there are 3 options for this exact purpose: FTP_BASE, FTP_CONTENT_DIR, FTP_PLUGIN_DIR.
Setting these has no affect.
This is confirmed by turning on debug and the following error is generated:
""Installation failed: Looking for /usr/local/www/+++++/www/wp-content/plugins in /""
The ""wp-admin/includes/class-wp-filesystem-base.php"" file reveals the find_folder function only processes the overrides for ftp services.
{{{
public function find_folder( $folder ) {
if ( isset( $this->cache[ $folder ] ) )
return $this->cache[ $folder ];
if ( stripos($this->method, 'ftp') !== false ) {
$constant_overrides = array(
'FTP_BASE' => ABSPATH,
'FTP_CONTENT_DIR' => WP_CONTENT_DIR,
'FTP_PLUGIN_DIR' => WP_PLUGIN_DIR,
'FTP_LANG_DIR' => WP_LANG_DIR
);
}}}
Seems to be a strange requirement on the ssh2 method that the paths must align exactly with the web server so I consider this a bug. Others may consider it an enhancement in which case it would be a good idea if the codex entry made it clear only ftp access methods support configurable paths (ssh must align with the webserver).",fsrs
Tickets with Patches,43990,Use wp_delete_file instead of unlink,,Filesystem API,,low,normal,Future Release,enhancement,assigned,has-patch,2018-05-07T14:35:43Z,2018-05-14T19:44:35Z,Use `wp_delete` instead of `unlink` as much as possible throughout the codebase.,macbookandrew
Tickets Awaiting Review,33332,Default ACL entries are not set correctly when file is uploaded to WP,,Filesystem API,4.1.1,normal,major,Awaiting Review,defect (bug),new,,2015-08-10T22:21:08Z,2019-02-07T07:30:14Z,"Hello there!
We are using ACL permissions on our server in order to isolate all websites from each other. Both nginx and php-fpm has it's own users. Actually, each website has it's own php-fpm user.
The ACL permissions are set for new files via default permission set:
{{{
getfacl -a ./sitename/wp-content/uploads
# file: sitename/wp-content/uploads
# owner: www-data
# group: www-data
user::rwx
user:nginx:r-x
user:fpm-sitename:rwx
group::rwx
mask::rwx
other::---
default:user::rwx
default:user:nginx:r-x
default:user:fpm-sitename:rwx
default:group::rwx
default:mask::rwx
default:other::---
}}}
So, when I manually create a file, the correct ACL permissions will be set for it by the filesystem itself:
{{{
$ sudo -u fpm-sitename touch test
$ getfacl ./test
# file: test
# owner: fpm-sitename
# group: fpm-sitename
user::rw-
user:nginx:r-x #effective:r--
user:fpm-sitename:rwx #effective:rw-
group::rwx #effective:rw-
mask::rw-
other::---
}}}
And nginx will be able to read and serve it.
However, when I upload a file through the WordPress it has no ACL entries at all.
I've looked through the code and the following part of the '''_wp_handle_upload()''' seems to be the culprit:
{{{
// Set correct file permissions.
$stat = stat( dirname( $new_file ));
$perms = $stat['mode'] & 0000666;
@ chmod( $new_file, $perms );
}}}
After commenting it out uploading works like a charm and proper ACL entries are set as expected.
We're using Ubuntu Server 14.04.3 LTS.
Cheers!",slavafomin
Unpatched Bugs,14401,Unable to locate WordPress Content directory (wp-content).,,Filesystem API,3.0,normal,normal,,defect (bug),reopened,,2010-07-23T15:56:19Z,2019-06-04T19:43:05Z,"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",pavelevap
Tickets Needing Feedback,19643,Allow array for $extra_fields in request_filesystem_credentials,dd32,Filesystem API,3.0,normal,minor,,defect (bug),reviewing,dev-feedback,2011-12-22T07:47:38Z,2019-06-04T19:43:38Z,The current implementation for passing extra fields through request_filesystem_credentials() does not allow for an array of data to be passed. I came across this issue when trying to process a bulk installation of plugins with my plugin installation class. My patch fixes this from what I can tell and doesn't break anything that I can see from my testing.,griffinjt
Unpatched Bugs,20652,"Install plugins with FTP upload, virtual subdomain, bad base dir?",dd32,Filesystem API,3.3,normal,normal,,defect (bug),reopened,,2012-05-10T12:02:48Z,2019-06-04T19:43:46Z,"Hi anybody!
I have problem with install plugins with FTP module in WP.
Everything show as OK, but plugin directory is bad. I have subdomain
sub.something.com - this is virtual subdomain from mod_rewrite
dirs are
/www/something.com/something.com[[BR]]
/www/something.com/sub.something.com - here is WP installation, subdomain is virtual from rewrite in httpd.conf
After install - WP say everything OK - but one thing is bad.[[BR]]
Upload is in bad directory - plugin I can found in[[BR]]
/www/something.com/something.com/plugins[[BR]]
no in /www/something.com/sub.something.com/plugins[[BR]]
Is here some way to fix it automatticaly or I can must edit config and basedir of ftp? Why is here this bug?
Thank you !
Pavel
",rajcz
Tickets with Patches,20716,Control how and when request_filesystem_credentials outputs creds form,dd32,Filesystem API,3.4,normal,normal,,enhancement,assigned,has-patch,2012-05-21T02:02:08Z,2019-06-04T19:43:49Z,"When using WP_Filesystem in a plugin or other external app, you can initialize it this way:
{{{
if ( false == ( $creds = request_filesystem_credentials( $url, $method, false, false, $form_fields ) ) ) {
return true;
}
}}}
Makes sense. If the method isn't direct or we don't have the credentials we need, `request_filesystem_credentials` outputs a form and returns false. Then we check again to make sure the credentials can be verified, and it not, we continue to output the form until the credentials are good.
{{{
if ( ! WP_Filesystem( $creds ) ) {
request_filesystem_credentials( $url, $method, true, false, $form_fields );
return true;
}
}}}
`request_filesystem_credentials` arbitrarily outputs the form whether you want it to or not, unless you explicitly filter the `request_filesystem_credentials` function itself. Using this in conjunction with Ajax, you have to use output buffering to catch the output and return it to the Ajax script for processing or else you get errors. This definitely isn't ideal.
I'd suggest storing the form in a variable and possibly pass a parameter that determines whether or not we want to actually output the form or not. Or, if there is another (better) way, that's cool too. Just some way to help `request_filesystem_credentials` determine how we want to interact with credentials should we need them.
",griffinjt
Unpatched Enhancements,22772,Introduce HOMEPATH,,Filesystem API,3.5,normal,normal,,enhancement,new,,2012-12-06T03:05:42Z,2019-06-04T19:44:19Z,"I was poking around with get_home_path() and wondering if there's any reason to not set a constant HOMEPATH (like ABSPATH) in the root index.php
I'd seem to be more reliable then get_home_path() and that function could simply return the new constant.
get_home_path has it's origins 8 years ago when the code was very different: [1567]",WraithKenny
Unpatched Bugs,23845,Install new theme via FTP failed,,Filesystem API,3.5.1,normal,normal,,defect (bug),new,,2013-03-22T12:19:03Z,2019-06-04T19:44:34Z,"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.",Przemyslaw Plewa
Unpatched Bugs,25741,Broken WP_Filesystem methods,,Filesystem API,,normal,normal,,defect (bug),new,,2013-10-28T03:18:03Z,2019-06-04T19:44:55Z,"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.",dd32
Unpatched Bugs,26802,WordPress FTP component fails to update core on IIS7+,dd32*,Filesystem API,3.7.1,normal,major,,defect (bug),accepted,,2014-01-09T21:35:50Z,2019-06-04T19:45: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.
",WinWPAdmin
Tickets with Patches,28616,ftp_fput should have a retry threshold,,Filesystem API,3.9,normal,normal,,defect (bug),new,needs-unit-tests,2014-06-23T18:27:07Z,2019-06-04T19:45:56Z,"In class-wp-filesystem-ftpext.php in put_contents(), ftp_fput() is called to transfer a file to the FTP server.
The first problem is that warnings are suppressed, so the user never knows that this is the location where something went wrong.
The broader problem is that a single transient network failure between the web server and FTP server causes this call to fail. Well, that would be not a big problem if the user's operation were a single call. However, this function is used by Wordpress auto-upgrade when direct file access fails. For each file in the Wordpress distribution, this function is called to transfer it to the FTP server.
As the default Wordpress distribution gets more and more bloated, the number of calls increases proportionally, and the likelihood of at least one FTP transaction failing increases. A single failure aborts the entire Wordpress upgrade. It seems reasonable to at least retry up to (say) three times the ftp_fput() call before returning an error to the higher level and aborting a large process such as Wordpress upgrade which is using FTP as backing for the filesystem abstraction layer.",runderwo
Unpatched Bugs,32774,Improve WP_Filesystem::dirlist() format consistency,,Filesystem API,,normal,minor,,defect (bug),new,,2015-06-24T07:05:58Z,2019-06-04T19:49:36Z,"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)",dd32
Unpatched Bugs,34327,Check for filesystem write permissions done based on ownership instead of actual filesystem permissions,,Filesystem API,4.3.1,normal,normal,,defect (bug),new,,2015-10-16T16:34:57Z,2019-06-04T19:52:31Z,"For security reasons, I don't run my httpd/fpm processes as the same user that owns my web content. This gives problems when trying to do various things in Wordpress such as updating themes/plugins/translations etc.
It all comes down to the function get_filesystem_method in wp-admin/includes/file.php, which bases the choice for direct filesystem access on the ownership of the filesystem resource(s) it's trying to access. Of course user ownership is not the only thing that can grant write permissions in the filesystem, the group owner and even things like ACL's can influence this.
I see that for WP updates there has already been a 'hack' made which is $allow_relaxed_file_ownership but there seems to be no way to use the same criteria for all other actions.
The core issue is that Wordpress bases its ""Can I actually write files $here"" decision not on the actual outcome of a filesystem action, but on assumptions about the file/directory owner being the sole factor in being able to write.
Please either
- allow a global 'allow_relaxed_file_ownership' setting, or
- actually perform a filesystem write check
so that people configuring their filesystem permissions properly don't need to lower their security in order to run Wordpress.
Thanks!",Sling1
Unpatched Bugs,36936,Plugin update does not works via web with proper filesystem permissions.,,Filesystem API,4.5.2,normal,normal,,defect (bug),new,,2016-05-24T21:09:30Z,2019-06-04T19:58:39Z,"Hello all,
I run Wordpress 4.5.2 on Ext4 file system with POSIX ACL.
Web server is Nginx, PHP runs as FPM daemon. Both under www-data user and group (for now).
When I try to update some plugin, Wordpress ask me to enter FTP credentials instead of doing update.
All output below was gathered under '''www-data''' account (PHP-FPM runs under it).
Here is my file system permissions:
'''Document root:'''
{{{
$ getfacl /var/www/html/
getfacl: Removing leading '/' from absolute path names
# file: var/www/html/
# owner: root
# group: root
user::rwx
user:www-data:r-x
group::---
group:SA:rwx
group:webdesigner:rwx
mask::rwx
other::---
default:user::rwx
default:user:www-data:r-x
default:group::---
default:group:SA:rwx
default:group:webdesigner:rwx
default:mask::rwx
default:other::---
}}}
'''wp-content'''
{{{
$ getfacl /var/www/html/wp-content/
getfacl: Removing leading '/' from absolute path names
# file: var/www/html/wp-content/
# owner: root
# group: root
user::rwx
user:www-data:rwx
group::---
group:SA:rwx
group:webdesigner:rwx
mask::rwx
other::---
default:user::rwx
default:user:www-data:rwx
default:group::---
default:group:SA:rwx
default:group:webdesigner:rwx
default:mask::rwx
default:other::---
}}}
'''Plugins'''
{{{
$ getfacl /var/www/html/wp-content/plugins/
getfacl: Removing leading '/' from absolute path names
# file: var/www/html/wp-content/plugins/
# owner: root
# group: root
user::rwx
user:www-data:rwx
group::---
group:SA:rwx
group:webdesigner:rwx
mask::rwx
other::---
default:user::rwx
default:user:www-data:rwx
default:group::---
default:group:SA:rwx
default:group:webdesigner:rwx
default:mask::rwx
default:other::---
}}}
'''Plugin to be updated:'''
{{{
$ getfacl /var/www/html/wp-content/plugins/postmatic/
getfacl: Removing leading '/' from absolute path names
# file: var/www/html/wp-content/plugins/postmatic/
# owner: root
# group: root
user::rwx
user:www-data:rwx
group::---
group:SA:rwx
group:webdesigner:rwx
mask::rwx
other::---
default:user::rwx
default:user:www-data:rwx
default:group::---
default:group:SA:rwx
default:group:webdesigner:rwx
default:mask::rwx
default:other::---
}}}
Despite user www-data is explicitly granted to have write permissions to all required directories, Wordpress fails to start upgrade from web and asks for FTP credentials.
I believe PHP works well enough with POSIX ACL, here is simply proof script:
{{{
$ php -r 'if (posix_access( ""/var/www/html/wp-content/"", POSIX_R_OK | POSIX_W_OK)) {
echo ""The file is readable and writable!\n"";
} else {
$error = posix_get_last_error();
echo ""Error $error: "" . posix_strerror($error);
}'
The file is readable and writable!
}}}
If there are some reason to keep current filesystem permission check method intact - please, issue spcecial technical note regarding required permissions and how does Wordpress checking it.
System information:
{{{
$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 14.04.4 LTS
Release: 14.04
Codename: trusty
$ php -v
PHP 5.5.9-1ubuntu4.16 (cli) (built: Apr 20 2016 14:31:27)
}}}
There are no SuPHP, Suhosin or any suspicious extensions.
This issue could be related to [https://core.trac.wordpress.org/ticket/34327]
Thank you.
",brudas
Unpatched Bugs,49403,WordPress prompts for FTP credentials to perform updates,,Filesystem API,5.3.2,normal,normal,,defect (bug),reopened,,2020-02-11T11:58:50Z,2020-03-03T06:04:02Z,"For some reason WordPress believes it does not have write permissions when in fact it does.
My configuration: Lighttpd running as www-data with PHP as fcgi.
Directory permissions are set to 770:user:www-data. During first time installation WordPress successfully creates wp-config.php, so there are no issues with permissions.
I have to add define(‘FS_METHOD’,’direct’); to wp-config.php to workaround this bug. But I cannot do this for all people I am providing hosting to. I keep getting asked why WP cannot update itself even when permissions are set to 777. It is also leaves people with non-updating WP installations and puts my server under risk of being turned into malware bot.
So, can you guys please fix the way WP detects if it has write access?",shadowlmd
Tickets Awaiting Review,50287,FS_METHOD=ssh2 breaks some plugins,,Filesystem API,5.4.1,normal,minor,Awaiting Review,defect (bug),new,has-patch,2020-05-30T21:44:41Z,2020-08-27T20:24:02Z,"Some plugins expect WS_Filesystem() call to work properly without options.
SSH2 method requires several options to work. When plugin does not call request_filesystem_credentials() it becomes broken by FS_METHOD=ssh2 constant.
WordPress can use FTP_* constants as defaults in WP_Filesystem_SSH2 when none options are provided to constructor.",denkoren
Tickets Awaiting Review,51368,Remove windows path check from validate_file,,Filesystem API,,normal,normal,Awaiting Review,defect (bug),new,,2020-09-21T12:38:21Z,2020-09-22T21:51:05Z,"Let's talk about `validate_file` function, and specifically about this fragment here:
https://github.com/WordPress/wordpress-develop/blob/b984a64c987ae259109bcb08776b1ed22f1dc98f/src/wp-includes/functions.php#L5373-L5376
It checks whether or not the path is a Windows drive path. Why is this logic needed? It doesn't seem to play any role or even make sense - why allow arbitrary unix paths, but not windows paths? It was introduced 16 years ago when the function was first created, and even then there was no clear explanation why is it even being checked: [2019].",zieladam
Tickets with Patches,48289,wp_normalize_path() breaks path_is_absolute() in Windows.,SergeyBiryukov,Filesystem API,5.2.3,normal,normal,Future Release,defect (bug),reviewing,needs-unit-tests,2019-10-11T08:49:20Z,2021-04-08T07:28:58Z,"Apologies in advance if this is considered correct behaviour, but it's strange that this is the case.
On **Windows**, when you take an absolute file system path and use `wp_normalize_path()` and then pass this result to `path_is_absolute()`, you get `false` instead of `true`.
Super simple demo:
{{{#!php
PHP Warning: ssh2_exec(): Unable to request command execution on remote host
and on those severs all calls to `WP_Filesystem_SSH2::chmod()` basically become noops.
Luckily, starting with version [https://pecl.php.net/package/ssh2/0.12 0.12], the ssh2 extension introduced [https://www.php.net/manual/en/function.ssh2-sftp-chmod.php ssh2_sftp_chmod()], and `WP_Filesystem_SSH2::chmod()` should be changed to use it.",pbiron
Tickets with Patches,55387,$wp_filesystem->dirlist() can return false and that should be checked for before iterating over the return value,pbiron,Filesystem API,2.8,normal,normal,Future Release,defect (bug),assigned,has-patch,2022-03-13T19:22:47Z,2022-04-30T16:17:06Z,"There are a number of cases in core (e.g., https://core.trac.wordpress.org/browser/trunk/src/wp-admin/includes/class-wp-upgrader.php#L500) where the return value of `$wp_filesystem->dirlist()` is assumed to be an array. But since that method can return `false`, we should always check for that before iterating (or calling `array_keys()` or `array_values()` on it) over the return value. ",pbiron
Candidates for Closure,55688,Update size function in WP_Filesystem_Direct,,Filesystem API,2.5,normal,normal,Awaiting Review,defect (bug),new,close,2022-05-06T04:48:11Z,2022-05-06T19:21:54Z,"Related: #55678
Replying to [comment:8 costdev]:
>
> [https://github.com/WordPress/wordpress-develop/pull/2677 PR2677] was discussed in the scrub. The PR patches a different function and this should be handled in a different ticket.
",mukesh27
Candidates for Closure,47817,Using file editor ignores schema and always uses http,,Filesystem API,5.2.2,normal,normal,Awaiting Review,defect (bug),new,reporter-feedback,2019-08-01T22:52:15Z,2023-03-11T03:26:19Z,"When editing a template/theme or plugin file with the WordPress file editor, the internal loopback which I assume uses wp-json does not honor the schema of the siteurl.
For example:
Siteurl: https://kinsta.com
The request will come through as http://kinsta.com
If SSL is forced at the server level, this will force the https:// schema.
This was recently discovered and was failing because a user's SSL intermediate chain was missing, so the site would edit fine without HTTPS forced, but with SSL forced it would fail.
We were able to identify the chain issue due to this error occuring when force HTTPS was enabled in Nginx:
```Unable to communicate back with site to check for fatal errors, so the PHP change was reverted. You will need to upload your PHP file change by some other means, such as by using SFTP.```",jeffpaulkinsta
Candidates for Closure,49719,PHP warning when updating ro_RO translation to latest version,,Filesystem API,5.3.2,normal,minor,Awaiting Review,defect (bug),new,reporter-feedback,2020-03-28T15:22:55Z,2023-03-12T02:10:55Z,"The PHP warning is this:
{{{
Warning: chmod(): Operation not permitted in /var/www/html/wp-admin/includes/class-wp-filesystem-direct.php on line 168
}}}
Everything seems to work fine after that. I have a big number of plugins but do not know how to test this with them disabled. I use a customized version of TwentyTwenty.
Thank you.",silviubogan
Tickets Awaiting Review,46561,Make wp_normalize_path() on Windows resolve drive letter for drive–relative paths,,Filesystem API,3.9,normal,minor,Awaiting Review,enhancement,new,dev-feedback,2019-03-19T09:18:48Z,2023-03-12T08:45:38Z,"Though rarely used, Windows allows to omit drive letter in file path to treat is as drive–relative.
This causes inconsistency where paths pointing to the same dir are not normalized to the same representation by `wp_normalize_path()`:
{{{#!php
mkdir( $_dir, FS_CHMOD_DIR ) && ! $wp_filesystem->is_dir( $_dir ) ) {
}}}
throws an error when checking if / is a directory and the entire unzip fails.
If I remove untrailingslashit from line 1655 (or wrap $dir in untrailingslashit as well) that check works as designed and the problem is avoided.",mwheelermindbox
Tickets with Patches,36710,Symlinked directories should not be deleted recursively,,Filesystem API,,normal,major,Future Release,defect (bug),new,has-patch,2016-04-28T21:51:47Z,2023-06-20T03:06:48Z,"When deleting a symlinked plugin, the current behavior is to recursively delete everything in the plugin's real directory and then fail to unlink the symlink because rmdir won't work on a symlink. This is probably not what the site admin intended when they installed the plugin via a symlink. The desired behavior is to unlink only the symlink, leaving the external directory intact so that other symlinks remain intact.
My patch fixes this in WP_Filesystem rather than in the plugin deletion logic because it seems generally applicable to the use cases for symlinks.
What makes this hard is that trailing slashes are significant when dealing with symlinked directories. The trailing slash causes the link to be followed:
{{{
is_link('/link/') => false
is_link('/link') => true
}}}
The patch fixes deletion of symlinked plugins: it unlinks the symlink and leaves the real files intact. It should be carefully checked against other uses of delete because they might not include the trailing slash. In such cases, adding a trailing slash to the new `is_dir()` check might help. Could be a minefield, could be fine.
Related to #29408 but not a duplicate.",andy
Candidates for Closure,57725,Use of rand() function instead of wp_rand(),,Filesystem API,,normal,normal,Awaiting Review,enhancement,new,dev-feedback,2023-02-15T11:14:13Z,2023-06-21T11:00:43Z,"Filesystem API function {{{wp_edit_theme_plugin_file}}} using PHP {{{rand()}}} function rather than WP's {{{wp_rand()}}}. Can we enhance this as {{{rand()}}} is discouraged?
File path: wp-admin/includes/file.php
Line: 524 and 526
",haritpanchal
Tickets Awaiting Review,35517,Work around PHP7 php-ssh2 breakage,,Filesystem API,,normal,normal,Awaiting Review,defect (bug),new,dev-feedback,2016-01-18T20:46:22Z,2023-06-27T06:41:29Z,"There is an updated php-ssh2 package available for PHP7, but it currently breaks the WordPress updater functionality for `class-wp-filesystem-ssh2.php`. The root cause seems to be that it has not correctly implemented the PHP stream wrappers for the `stat()` call, and any dependent functions such as `is_file()`, `is_dir()`, `file_exists()`, etc.
However, the `ssh2_sftp_stat()` function does work, and we can deduce the other information from it.
I've filed a bug against the php-ssh2 extension (https://bugs.php.net/bug.php?id=71376), but I wondered if using `ssh2_sftp_stat()` might be better, in general, than depending on the PHP stream wrapper functionality.
",dougal
Candidates for Closure,56301,Add File Backup Feature in wp_edit_theme_plugin_file(),sajjad67,Filesystem API,,normal,normal,Awaiting Review,feature request,assigned,dev-feedback,2022-07-28T22:23:00Z,2023-07-17T15:07:22Z,"I thought about the security before creating this ticket, but still let's discuss about the possibility of it for once! The way it works now is if you edit a file using the plugin/theme-editor.php, there's no way of going back! It only checks for any Fatal Error!
Now what i think, would it be good/bad if we add a feature to create a (temp) backup of each file edited, like we do for posts/pages as revisions! There's lots to take into consideration before we discuss about it, i know! But is there anyone else thinking like me this could be a feature!!
Let me know if it's open for any further discussion!",sajjad67
Candidates for Closure,52575,"get_home_path() returns ""/"" instead of path to WordPress directory",,Filesystem API,5.6.1,normal,major,Awaiting Review,defect (bug),new,dev-feedback,2021-02-19T12:28:50Z,2023-07-18T01:34:51Z,"Wrong return value from get_home_path() in /wp-admin/includes/file.php
[https://developer.wordpress.org/reference/functions/get_home_path/]
Expected result: Absolute filesystem path to the root of the WordPress installation
Result in situation below: /
**Context**
A WordPress in its own directory installed according method II mentioned here
https://wordpress.org/support/article/giving-wordpress-its-own-directory/
**Settings** (Example)
Wordpress: https://pixellogik.de/wp
Website: https://pixellogik.de
Plugin WP-SCSS installed
**Reproduce**
Open https://pixellogik.de in a browser
The plugin calls get_home_path() in enqueue_files() in line 213
/www/htdocs/w012345/pixellogik.de/wp/wp-content/plugins/wp-scss/class/class-wp-scss.php
Due to the unexpected value ""/"" of get_home_path() the URL of the generated CSS file does not point to a file.
The CSS won't be loaded, the site looks scrambled.
**What went wrong?**
If SCRIPT_FILENAME is outside the installation directory, the directory can't be found. This case is not handled, hence value ""/"" is returned
**Possible fix:**
return ABSPATH in that case",pixellogik
Unpatched Bugs,24780,Use error handlers rather than the error suppression operator,,Filesystem API,,normal,normal,Future Release,defect (bug),new,,2013-07-17T01:14:56Z,2023-09-07T09:39:17Z,"In various places in core (and included libraries, such as pclzip, FTP and phpass), the error suppression operator is used to suppress warnings and notices. However, this also suppresses fatal errors, which makes it a huge pain for debugging.
The big one here is `fopen`, where it is used to suppress warnings when opening a handle fails. For normal files, this is fine since the only errors generated are warnings. When using streams and custom stream handlers, these can generate errors which are really hard to find with this.
(I ran into this with the App Engine plugin, where the SDK method generates a fatal error if the mode is `a`, which is used with error suppression in `win_is_writable()`.)",rmccue
Tickets Awaiting Review,59729,"By setting int to the parameter of the function path_is_absolute(), a Notice will always be output.",,Filesystem API,2.5,normal,trivial,Awaiting Review,defect (bug),new,,2023-10-25T10:12:11Z,2023-10-25T10:12:11Z,"I found this problem from my client's server logs.
The simplest way to reproduce it is as follows.
{{{
% wp eval 'var_dump(path_is_absolute(1));'
PHP Warning: Trying to access array offset on value of type int in /var/www/html/wp-includes/functions.php on line 2123
Warning: Trying to access array offset on value of type int in /var/www/html/wp-includes/functions.php on line 2123
PHP Warning: Trying to access array offset on value of type int in /var/www/html/wp-includes/functions.php on line 2133
Warning: Trying to access array offset on value of type int in /var/www/html/wp-includes/functions.php on line 2133
bool(false)
}}}
This occurs because the first character of String is processed as an array within the function.
The client had written code like this:
{{{
$new_path = path_join( $path, get_the_ID() );
}}}
I think get_the_ID() should be cast to String, but why not make the function return False if it's not a String as well?",mt8.biz
Tickets Needing Feedback,58541,WP_Filesystem_SSH2:put_contents (and others) does not check for $sftp_link to be up,,Filesystem API,,normal,major,Future Release,defect (bug),new,dev-feedback,2023-06-15T06:47:39Z,2023-10-27T14:18:47Z,"This is a bit long, as I need to explain the reason why it is a problem not to check for the link '$sftp_link' to be up.
In short: WordPress allows choosing between various FS_METHODS (wp-config.php), e.g. 'direct' or 'ssh2'. While neither choice will affect WordPress updating itself at all, it has implications when some plugins updating files writing content to a file (htaccess, css etc) via
{{{
$wp_filesystem->put_contents($file, $content);
}}}
The function put_contents should check whether the link is up.
There is a big difference how one needs to setup the '$wp_filesystem' instance if you use 'direct' or 'ssh2' - the first one does not need to connect, the second needs to setup a connection before being able to write.
For FS_METHODS 'direct':
{{{
global $wp_filesystem;
if(empty($wp_filesystem))
{
require_once ABSPATH . '/wp-admin/includes/file.php';
WP_Filesystem();
}
$wp_filesystem->put_contents($file, $content);
}}}
For FS_METHODS 'ssh2':
{{{
global $wp_filesystem;
if(empty($wp_filesystem))
{
require_once ABSPATH . '/wp-admin/includes/file.php';
WP_Filesystem();
// this is the ONLY difference to 'direct'
$wp_filesystem->connect();
}
$wp_filesystem->put_contents($file, $content);
}}}
In the file ABSPATH/wp-admin/includes/file.php (around line 2051) the function WP_Filesystem() simply sets up an instance of the class defined by FS_METHOD, but does NOT connect if FS_METHOD is set to 'ssh2'.
Now many plugins that need to write a file (css,htacess,etc) simply assume that FS_METHOD is set to 'direct' or even assume WP_Filesystem() will connect as well.
I have three plugins (there are more, but these are the ones I am 100% sure) that have problems writing
- Ultimate Addons for Elementor
- Astra Addons
- Sensei
Now I could tell those developers to do it properly.
However I think the function $wp_filesystem->put_contents() should CHECK whether the link is up and if NOT, call a function within the class and setup the link to the server, after all I would consider this is proper coding pratice.
{{{
public function put_contents( $file, $contents, $mode = false ) {
// so this is for people who come from the outside
// just setting up the class and dont care whether
// a call to ""connect"" is required.
error_log(""class-wp-filesystem-ssh2.php -> put_contents -> $file "");
if(!$this->sftp_link)
{
error_log(""class-wp-filesystem-ssh2.php link is null, connecting ...."");
// this function is similar to connect
$rc = $this->build_options_connect();
}
// put the contents
$ret = file_put_contents( $this->sftp_path( $file ), $contents );
if ( strlen( $contents ) !== $ret ) {
return false;
}
$this->chmod( $file, $mode );
return true;
}
}}}
The function $this->build_options_connect() sets up the required data structure similar to the function ""request_filesystem_credentials()"" in file ABSPATH/wp-admin/includes/file.php (around line 2250) and then sets up the connection similar to the function $wp_filesystem->connect() in file ABSPATH/wp-admin/includes/class-wp-filesystem-ssh2.php (around line 120).
I have done this on all of my servers for a few weeks now.
Message like this one example (of many) below have completely disappeared.
{{{
[10-Jun-2023 18:25:12 UTC] PHP Warning: file_put_contents(ssh2.sftp:///HIDDEN/htdocs/wp-content/uploads/uael_uploads/.htaccess): failed to open stream: operation failed in /HIDDEN/htdocs/wp-admin/includes/class-wp-filesystem-ssh2.php on line 283
}}}
While I stated 'has patch' (I do), let's first see what people say about this.",jobst
Unpatched Bugs,28013,WP_Filesystem_FTPext::exists($filename) returns false when file exists on FTP Service ( IIS/6.0 Microsoft & Linux/vsftp ),dd32,Filesystem API,3.9.2,normal,normal,Future Release,defect (bug),reopened,close,2014-04-24T15:33:56Z,2024-01-04T21:18:58Z,"I'm having trouble using the update/upgrade functions of WordPress on a Windows IIS/6.0 server.
The .maintenance file is never deleted.
I have to use the FTPext method of updating and I've found that `WP_Filesystem_FTPext::exists('.maintenance')` returns false even though the file exists.
Since the fix for #10060 that function uses `ftp_nlist()` which returns invalid results on the IIS/6.0 Microsoft FTP Service.
I did some more testing and it turns out that the current function has issues with ""dotfiles""
'''Work correctly'''
`WP_Filesystem_FTPext::exists('index.php')`
`WP_Filesystem_FTPext::exists('wp-content/debug.log')`
'''Fail'''
`WP_Filesystem_FTPext::exists('.maintenance')`
`WP_Filesystem_FTPext::exists('wp-content/.maintenance')`
(yes, I made sure those files actually existed ;-)
For this particular purpose, couldend `WP_Upgrader::maintenance_mode()` be modified to test for the existence of .maintenance using `is_file( ABSPATH . $file )` and if so execute `$wp_filesystem->delete($file, false, 'f');` (setting the f bypases all the tests)?",joostdekeijzer
Tickets Awaiting Review,51340,Stop chmodding files and folders,,Filesystem API,5.3,normal,major,Awaiting Review,defect (bug),new,dev-feedback,2020-09-18T08:38:34Z,2024-02-02T12:07:42Z,"WP's filesystem handler has a chmod function, that is used e.g. when updating,...
To conform with standards, enforce proper usage of umask by the server admin as well as avoid errors when the file owner is not the same as the user running WP, WP should not be chmodding files whatsoever.
Linux, for obvious security reasons, only allows chmod for the owner of the file (independent of permissions, except root).
Thus, it makes sense to have the WP files owned by user A, but run php(-fpm) by user B.
When WP now tries to chmod, which it shouldnt, as we have established that may cause a security issue, it will obviously create a PHP error.",malthert
Slated for Next Release,48689,PHP warnings after updating to WP 5.3: ftp_nlist() and ftp_pwd() expect missing parameters,costdev,Filesystem API,5.3,normal,minor,6.6,defect (bug),assigned,needs-unit-tests,2019-11-17T23:24:37Z,2024-02-06T05:48:16Z,"I updated several websites to WP 5.3 without any problems. But on one wesite I got these PHP warnings both in the backend and in the website:
{{{
Warning: ftp_nlist() expects parameter 1 to be resource, null given in /wp-admin/includes/class-wp-filesystem-ftpext.php on line 402
Warning: ftp_pwd() expects parameter 1 to be resource, null given in /wp-admin/includes/class-wp-filesystem-ftpext.php on line 226
Warning: ftp_pwd() expects parameter 1 to be resource, null given in /wp-admin/includes/class-wp-filesystem-ftpext.php on line 226
Warning: ftp_pwd() expects parameter 1 to be resource, null given in /wp-admin/includes/class-wp-filesystem-ftpext.php on line 226
Warning: ftp_nlist() expects parameter 1 to be resource, null given in /wp-admin/includes/class-wp-filesystem-ftpext.php on line 402
Warning: ftp_pwd() expects parameter 1 to be resource, null given in /wp-admin/includes/class-wp-filesystem-ftpext.php on line 226
Warning: ftp_pwd() expects parameter 1 to be resource, null given in /wp-admin/includes/class-wp-filesystem-ftpext.php on line 226
Warning: ftp_pwd() expects parameter 1 to be resource, null given in /wp-admin/includes/class-wp-filesystem-ftpext.php on line 681
Warning: ftp_pwd() expects parameter 1 to be resource, null given in /wp-admin/includes/class-wp-filesystem-ftpext.php on line 226
Warning: ftp_pwd() expects parameter 1 to be resource, null given in /wp-admin/includes/class-wp-filesystem-ftpext.php on line 226
Warning: Cannot modify header information - headers already sent by (output started at /wp-admin/includes/class-wp-filesystem-ftpext.php:402) in /wp-includes/functions.php on line 5946
Warning: Cannot modify header information - headers already sent by (output started at /wp-admin/includes/class-wp-filesystem-ftpext.php:402) in /wp-admin/includes/misc.php on line 1252
Warning: Cannot modify header information - headers already sent by (output started at /wp-admin/includes/class-wp-filesystem-ftpext.php:402) in /wp-admin/admin-header.php on line 9
}}}
I suppressed the ouput by ""muting"" the function calls with '@' in the file 'class-wp-filesystem-ftpext.php', i.e. changed {{{ftp_nlist()}}} to {{{@ftp_nlist()}}} etc..
I will be glad if any reason can be found and fixed until the next WP upgrade.
",Hinjiriyo
Tickets Needing Feedback,48316,"Changeset 46482 breaks upload when using "".."" in upload_path.",,Filesystem API,5.2.4,normal,normal,,defect (bug),reopened,dev-feedback,2019-10-15T21:01:42Z,2024-02-07T13:39:06Z,"Hi,
We just found out that changeset [46482] in the latest WordPress 5.2.4 broke a huge number of our customer's sites (tens or thousands).
We uses a separate subdomain as upload directory. This is done by changing the option ""upload_path"" to ""../../media.example.com/www/"" (and ""upload_url_path"" to ""http://media.example.com"").
This change means that new directories (for example ""./2019/10/"") can't be created, which breaks the entire upload functionality.
If this changeset fixed some critical vulnerability which can't be fixed another way or if we are the only ones utilizing this feature, so be it. Otherwise this change might have to be reverted and reimplemented some other way.
",xpoon
Tickets with Patches,44083,Add action to wp_mkdir_p() when directory is created successfully,SergeyBiryukov,Filesystem API,2.0.1,normal,normal,Future Release,enhancement,reviewing,has-patch,2018-05-15T00:11:46Z,2024-02-12T22:26:12Z,"It would be nice if the `wp_mkdir_p()` function contained a hook for plugins to interact with when a directory gets created.
The use-case I have currently is that Easy Digital Downloads (for example) creates `.htaccess` files and empty `index.php` files in its own `uploads/edd` directory, and each directory inside it, as one way of protecting those empty directories from being publicly browsable.
Because there is no action hook here, EDD uses a daily transient, which leaves new directories potentially open until the transient expires.
An action hook on directory creation would allow for EDD to create those files immediately.",johnjamesjacoby
Slated for Next Release,59917,"On windows host using ftp, Undefined array key ""islink""",,Filesystem API,,normal,normal,6.6,defect (bug),new,,2023-11-16T18:02:27Z,2024-02-17T13:48:42Z,"Fresh install of wordpress 6.4.1
On windows host using ftp
steps to recreate:
1. Going to ""sitehealth"" page gives critical warning ftp credentials are missing for updates.
2. Google search suggested adding the following to the user added section of `wp-config.php`
{{{
define('FTP_USER', 'USERNAME');
define('FTP_PASS', 'PASSWORD');
define('FTP_HOST', 'FTP.EXAMPLE.COM');
}}}
3. After this, go back to site health page. It is giving the following warnings repeatedly:
{{{
Warning: Undefined array key 3 in C:\...\wp-admin\includes\class-ftp.php on line 457
Warning: Undefined array key ""islink"" in C:\...\wp-admin\includes\class-wp-filesystem-ftpsockets.php on line 695
Warning: Undefined array key ""perms"" in C:\...\wp-admin\includes\class-wp-filesystem-ftpsockets.php on line 700
Warning: Undefined array key ""islink"" in C:\...\wp-admin\includes\class-wp-filesystem-ftpsockets.php on line 695
}}}",antonmo