[wp-trac] [WordPress Trac] #29610: FTPext Filesystem class can't detect isWritable, isReadable correctly
WordPress Trac
noreply at wordpress.org
Tue Nov 11 01:58:49 UTC 2014
#29610: FTPext Filesystem class can't detect isWritable, isReadable correctly
----------------------------+------------------------------
Reporter: programmin | Owner:
Type: defect (bug) | Status: new
Priority: normal | Milestone: Awaiting Review
Component: Filesystem API | Version: 2.5
Severity: normal | Resolution:
Keywords: | Focuses:
----------------------------+------------------------------
Comment (by programmin):
Replying to [comment:3 dd32]:
> Replying to [comment:2 programmin]:
> > it looks like it never checks permissions when upgrading WP plugin.
>
> Correct, we never check writability for FTP, and the only write checks
are done to determine if it should use FTP or direct file operations.
>
> Realistically, None of the functions mentioned here should've been
implemented for either the FTP or Direct filesystem wrappers.
Why not, can you please clarify? Btw I was using direct on a testing
system that had not had FTP mode set up, when I got the plugin to break as
described above. If even one of the folders of a plugin is not writable,
it deletes the rest and stays that way. (same thing happens if it fails to
copy fully for whatever reason).
I'm wondering why it does not check these permissions, and also does not
allow removal of broken plugin-directory when installing the plugin again?
In Plugin_Upgrader class:
{{{
$this->run( array(
'package' => $package,
'destination' => WP_PLUGIN_DIR,
'clear_destination' => false, // Do not overwrite
files.
'clear_working' => true,
'hook_extra' => array(
'type' => 'plugin',
'action' => 'install',
)
) );
}}}
Why not overwrite the files?
--
Ticket URL: <https://core.trac.wordpress.org/ticket/29610#comment:4>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list