Make WordPress Core

Opened 2 years ago

Last modified 16 months ago

#55328 new defect (bug)

PHP warning on rename() inside download_url() in /wp-admin/includes/file.php

Reported by: devbd's profile devbd Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version: 5.9
Component: Filesystem API Keywords: dev-feedback
Focuses: Cc:


Hi, I struggle with the following warning on my WordPress site (version 5.9.0 and currently 5.9.1) whenever I update the plugins:

PHP Warning: rename(/tmp/plugin-name.tmp, Permission denied in /wp-admin/includes/file.php on line 1201, referer: siteURL/wp-admin/plugins.php

The warning is triggered by rename() function inside download_url()in /wp-admin/includes/file.php on line 1201. It's been logged on the site since support for Content-Disposition filename was added in WP 5.9: The warning is also getting logged in WP 5.9.1.

My site uses ftpext filesystem and I believe this is why 'permission denied' warning is triggered. The plugins update successfully, with no other issues, however, the above warning is logged every single time. Would it be possible to exclude Content-Disposition filename support if website uses ftpext filesystem method?

Change History (3)

This ticket was mentioned in Slack in #core-auto-updates by afragen. View the logs.

2 years ago

#2 follow-up: @costdev
17 months ago

  • Keywords dev-feedback added

Hi @devbd, welcome to Trac and thanks for opening this ticket!

Pinging @johnjamesjacoby for thoughts on possibly using $wp_filesystem methods for download_url().

#3 in reply to: ↑ 2 @johnjamesjacoby
16 months ago

Replying to costdev:

Pinging @johnjamesjacoby for thoughts on possibly using $wp_filesystem methods for download_url().

I started researching this idea when I saw your mention.

I love it, and it is achievable. My two concerns are the level-of-effort to replace the innards, and being very careful not to introduce unintended changes that come from using that API (like showing FTP credential modals, redirects, etc...)

Relative to this, are inconsistencies across the WP Filesystem API subclasses for which PHP notices are silenced with @. In theory, download_url() could just do @rename() if that's what the Filesystem API is doing anyways, etc...

IMO – there is more research to do, compile, and share here, but I am confident we can address these notices in the short-term, and work towards the Filesystem API in the long! 🙌

Note: See TracTickets for help on using tickets.