WordPress.org

Make WordPress Core

Opened 7 years ago

Closed 7 years ago

Last modified 7 years ago

#5586 closed enhancement (fixed)

One click plugin updates

Reported by: lawrencejob Owned by: ryan
Milestone: 2.5 Priority: normal
Severity: blocker Version: 2.3.1
Component: Administration Keywords: installer theme plugin ftp zip updater
Focuses: Cc:

Description

I noticed that there was already a mention of this before, two years ago, but it did not really get much of a response and the solution (presented in a link) has since become invalid.

I wanted to suggest that themes and plugins can be uploaded and unzipped into the appropriate directory by wordpress by default.

I have a working solution, but I would like to share it with others, the only problem is that I doubt it will work on most servers (the unzip method uses the system(); php command which is normally not aloud). The rest of the code could be used.

I'll try and look at it some more some time if I can but it is unlikely I will have the time any time soon.

I just think its a neat feature that could make a huge difference to the UI without too much work.

I'll try and upload a zip that uploads to the wp-content folder.

It's even possible to create a WP own theme system ie *.wpp and *.wpt if you could.

Attachments (21)

My start of an autoinstaller.zip (5.3 KB) - added by lawrencejob 7 years ago.
My feeble attempt
upgrade_plugin.zip (45.5 KB) - added by ryan 7 years ago.
5586.diff (2.8 KB) - added by DD32 7 years ago.
5586.2.diff (1.0 KB) - added by DD32 7 years ago.
Silence Errors for non-existant directories & deletes.
plugin-install.zip (4.3 KB) - added by DD32 7 years ago.
POC of a Extension of this for a web based plugin installer for any plugin from WordPress.org
5586.3.diff (6.1 KB) - added by DD32 7 years ago.
5586.4.diff (5.1 KB) - added by DD32 7 years ago.
Better WP location search / Allow blank files in installer
5586.5.diff (706 bytes) - added by DD32 7 years ago.
Fatal Error fix
5586.6.diff (486 bytes) - added by DD32 7 years ago.
5586.7.diff (564 bytes) - added by DD32 7 years ago.
5586.8.diff (690 bytes) - added by DD32 7 years ago.
Critical: updater deletes entire plugins folder if upgrade a plugin which exists as a single file.
5586.9.diff (9.6 KB) - added by DD32 7 years ago.
5586.10.diff (3.6 KB) - added by DD32 7 years ago.
Allow FTP details to be hard-coded
5586.11.diff (981 bytes) - added by DD32 7 years ago.
5586.12.diff (972 bytes) - added by DD32 7 years ago.
5586.13.diff (388 bytes) - added by DD32 7 years ago.
5586.14.diff (1.1 KB) - added by DD32 7 years ago.
5586.15.diff (3.8 KB) - added by DD32 7 years ago.
Support certain Dedicated server setups.
download-url-wp_error.diff (2.0 KB) - added by DD32 7 years ago.
Return WP_Error from download_url() on HTTP Errors
5586.16.diff (4.1 KB) - added by DD32 7 years ago.
includes changes from download-url-wp_error.diff
5586.17.diff (478 bytes) - added by DD32 7 years ago.
add missing(yet unused by WordPress) method chdir() in Direct FS wrapper

Download all attachments as: .zip

Change History (107)

@lawrencejob7 years ago

My feeble attempt

comment:1 @ffemtcj7 years ago

  • Cc ffemtcj added

comment:2 @ffemtcj7 years ago

Upload your changes as a .diff so that we can see it in our browsers please.

comment:3 @DD327 years ago

I recently installed Gallery2, And i must say i was blown away by how smooth and integrated the plugin install was, IMO, WordPress really needs something similar.

As part of Googles Summer of Code 2007, I wrote a plugin which does exactly this, unfortunately since then, i've had little time to work on it, So i'm not sure if it works with 2.4/2.5 still.

The entire plugin can be checked out from this svn: http://wordpress-soc-2007.googlecode.com/svn/trunk/dd32.crazyman/trunk/ (Please checkout into a 'wp-update' plugin folder) - also note that it'll take over the plugins page, so the (now) inbuilt update checker will be unavailable while its enabled.

comment:4 follow-up: @ryan7 years ago

DD32, the organization of the wp-filesystem stuff is nice. I'd like to abstract things down to wp_upgrade_plugin() and wp_upgrade_theme() calls that can be unit tested, and make use of the update checking that is now in core.

comment:5 in reply to: ↑ 4 @DD327 years ago

Replying to ryan:

DD32, the organization of the wp-filesystem stuff is nice. I'd like to abstract things down to wp_upgrade_plugin() and wp_upgrade_theme() calls that can be unit tested, and make use of the update checking that is now in core.

Be my guest, If any of the code in there is of use, then use it :)

I tried to design it in such a way that various filesystem access methods would be transparent regardless of what the connection was, It should also be possible to add other access methods in without changing any other code if the need arrises.

comment:6 @ryan7 years ago

  • Owner changed from anonymous to ryan

comment:7 follow-up: @darkdragon7 years ago

You mean like #4779

comment:8 @lawrencejob7 years ago

darkdragon.. what?

comment:9 in reply to: ↑ 7 ; follow-up: @DD327 years ago

Replying to darkdragon:

You mean like #4779

That would be nice for fetching of the themes and data, Infact, most of my plugins would love that to be included in core :)

comment:10 in reply to: ↑ 9 ; follow-up: @darkdragon7 years ago

  • Keywords changed from installer, theme, plugin to installer theme plugin

Replying to DD32:

Replying to darkdragon:

You mean like #4779

That would be nice for fetching of the themes and data, Infact, most of my plugins would love that to be included in core :)

Wow! That is something coming from you.

I would too, since well, I spent a long time writing it and everything. However, it does not have any support for FTP, which from what ryan has stated is a requirement that would need to be met.

comment:11 in reply to: ↑ 10 @DD327 years ago

Replying to darkdragon:

Replying to DD32:

Replying to darkdragon:

You mean like #4779

That would be nice for fetching of the themes and data, Infact, most of my plugins would love that to be included in core :)

Wow! That is something coming from you.

I would too, since well, I spent a long time writing it and everything. However, it does not have any support for FTP, which from what ryan has stated is a requirement that would need to be met.

I mainly meant that for fetching external documents, Currently i've been using snoopy(but that doesnt work everywhere), WP tends to use fsockopen(but that doesnt work anywhere).

IMO, your classes would be great replacement for all that.

The classes refered to by ryan was for Filesystem access, Its a wrapper for various FTP methods/Direct filesystem methods, Its not designed to fetch remote documents, rather to modify the files on the local filesystem, Due to the number of different server setups, its never good to assume that you can just write to/from the public dir, That might lead to files being owned by different users(the Daemon process), different permissions, or permission denied errors. Those classes are designed to wrap around all that, and use Direct if possible, PHP 5's ftp function if available, Else a socket FTP access method.

Personally i think my WpFS code with a fair bit of cleanup, and your HTTP access code would greatly simplify whats needed for this ticket.

comment:12 @darkdragon7 years ago

Perhaps that is what it needs. A decoupled HTTP Request API would allow for retrieving Plugins and help plugins and WordPress retrieve other external sources on any number of server configurations.

A decoupled File System API would allow for manipulating files on many different server configurations. The scope of which could extend outside of updating WordPress and could be very useful elsewhere.

Once those two components get in, the amount of changes required for adding an update system would be administrative and functionality specifically for updating WordPress.

I think limiting the scope could reduce the amount of surprises and benefit everyone, even if this feature doesn't get introduced until 2.6 (worst case). At least the two components that will allow it to happen will be able to be battle tested in 2.5 and leading up to 2.5.

comment:13 @darkdragon7 years ago

Also, adding the different components separately would reduce stress of such a major addition.

Oh yeah, this is set for 2.7. Sigh. This is probably one of the issues that only get hit up every so often.

comment:14 @ryan7 years ago

  • Milestone changed from 2.7 to 2.5

comment:15 @ryan7 years ago

There, 2.5. :-)

comment:16 @ryan7 years ago

Patch makes use of DD32's filesystem classes. To test, bump the version of your copy of akismet down a ver and delete update_plugins from the options table. This will force an update of the plugin update info. In the "new version is available" notice on the plugins page there is an "upgrade automatically" link. If your web server is setup with suPHP, the upgrade doesn't need any additional info. If that's not available, FTP is used. To upgrade via FTP, you need to define FTP_HOST, FTP_USER, and FTP_PASSWORD in your wp-config.php. I'm still debugging the ftpext and ftpsockets classes. ftpext is working well enough with the FTP server that comes with Mac OS X Leopard.

This is still very rough. Lot's of error checking and feedback as well as friendlier FTP configuration need to be added. Downloading the new plugin zip, extracting it, and copying it into place are all done in the same page load. This may need to be broken up so that slow updates don't timeout. Updates against my local testbed were very fast, however.

@ryan7 years ago

comment:17 @ryan7 years ago

(In [6779]) First cut at plugin update. Props DD32 for the filesystem abstraction. see #5586

comment:18 @ryan7 years ago

Committed a minimalist first pass. Let's see if we can stabilize this in time for 2.5. If we can't, we'll strip it out and move it to 2.6. This uses DD32's filesystem abstraction. I decided not to do the chmod 777 thing like so many plugins do. If the server is running as the user, the code will do direct writes to the filesystem, otherwise FTP is used. Right now ftp is forced for testing purposes. ftpext works for me on the ftp servers I tested against. ftpsockets needs work to bring it up to speed with the changes to ftpext. Lot's more error checking and user feedback is needed.

comment:19 @ryan7 years ago

(In [6785]) ftp fs tweaks. see #5586

comment:20 @ryan7 years ago

(In [6914]) Fix ftpext dirlist for ftp servers that return 8 fields instead of 9. see #5586

comment:21 @DD327 years ago

Just had a play around with it.

I dont have FTP access to my dev box, only local FS, So i've updated the fs-direct class, and fixed a few bugs the updater was coming up with.

It was also deleteing *all* plugins from the plugins folder.

ie, updating /plugins/sitemap.php would delete all files in plugins/ and install the new version into google-sitemap-plugin/sitemap.php (as expected).

It looks like the FTP extension uses relative paths, While the direct uses absolute paths(which is needed AFAIK), So i've added another check to the delete plugin dir. line.

Attaching patch shortly.

comment:22 @DD327 years ago

Not sure why the diff includes line ending changes, I dont have a hex editor handy, but maybe the files in WP at present have \n (my editor uses \r\n)

@DD327 years ago

comment:23 @ryan7 years ago

[6919] fixes the eol-style.

comment:24 @ryan7 years ago

(In [6920]) fs direct fixes from DD32. see #5586

comment:25 follow-up: @DD327 years ago

Just a quick note.
I'm having troubles with PclZip on a certain server with the archives from wordpress.org I've not tested many, but exact same script & file works locally, Yet fails on the server.

The issue is happening around like 4595:

$v_bytes = ($v_bytes << 8) | Ord($v_byte); 

Completely different results between my local system (AMD64 X2 + XP 32bit SP2 + Apache 2.2+ php5.2.4), and the server (Linux creep 2.6.16.1 #3 SMP Sat Apr 1 16:37:28 WST 2006 x86_64 GNU/Linux + Apache + PHP 5.0.5-2ubuntu1.8 & PHP 4.4.0-3ubuntu2)

I'm no good at bitwise maths, So i'm unsure whats happening..

Also, Version 2.6 is out, There doesnt appear to be any changes related that are required.

http://www.phpconcept.net/pclzip/index.en.php

comment:26 @ffemtcj7 years ago

  • Cc ffemtcj removed

comment:27 @DD327 years ago

looking around for alternate Zip methods..

There seems to be 2 main options other than the pure php method, the Zip PHP extension, The Zlib extension(must be specifically loaded on linux, windows has it compiled in).

Of course.. Could just use Tar instead, or invent a new compressed format, or write a Zip handler from scratch that somehow manages to work around integer overflows/limits

Has anyone else come accross any problems with the plugin upgrading functions?

comment:28 @ryan7 years ago

Some errors with ftpsockets:

PHP Warning:  Invalid argument supplied for foreach() in /home/.../public_html/blog/wp-admin/includes/class-wp-filesystem-ftpsockets.php on line 270
PHP Fatal error:  Call to undefined method: ftp->settype() in /home/.../public_html/blog/wp-admin/includes/class-wp-filesystem-ftpsockets.php on line 138

@DD327 years ago

Silence Errors for non-existant directories & deletes.

comment:29 @DD327 years ago

attachment 5586.2.diff added.
Silence Errors for non-existant directories & deletes.

::is_dir() and ::delete() may call for files to be deleted / folders to be accessed that do not exist / are not actually folders, Can cause PHP notices to pop up.

@DD327 years ago

POC of a Extension of this for a web based plugin installer for any plugin from WordPress.org

comment:30 @DD327 years ago

attachment plugin-install.zip added.

POC of a Extension of this for a web based plugin installer for any plugin from WordPress.org

Will be creating a seperate Trac ticket for this for 2.6, Re-uses much of the code from the current upgrade methods. I just wanted to get this out there for now. I'll flesh it out more and release this as a plugin shortly.

comment:31 @ryan7 years ago

(In [7039]) Silence some exected warnings in ftpext. Props DD32. see #5586

comment:32 follow-up: @ryan7 years ago

Sweet DD32. I think that would be nice for integration in 2.6.

I think we can do wp_install_plugin() for 2.5. Have a file chooser in the Get More Plugins section of plugins.php that allows selecting a package that the user has already downloaded.

comment:33 in reply to: ↑ 32 @DD327 years ago

Replying to ryan:

Sweet DD32. I think that would be nice for integration in 2.6.

My thinking too, See #6015

I think we can do wp_install_plugin() for 2.5. Have a file chooser in the Get More Plugins section of plugins.php that allows selecting a package that the user has already downloaded.

That could work, But is it needed? An extra tab in the install of 2.6 to install from zips that are already on the filesystem(Maybe dumped in the wp-content/ folder) could work too.

comment:34 @ryan7 years ago

(In [7126]) Plugin updater updates. see #5586

comment:35 @DD327 years ago

+ $fs->setDefaultPermissions( $fs->getchmod($tmppath) );
+ $fs->mkdir($tmppath, 0755);

I noticed that in [7126], Is 0755 the best for the folder? It neads read/write for owner, read for group/everyone.

Which according to http://www.ezau.com/latest/tools/chmod.html would be 0644 which is what i'd more expect.

comment:36 follow-up: @ryan7 years ago

Setting the execute bit on directories makes sure dir listing and traversal is allowed.

comment:37 in reply to: ↑ 36 @DD327 years ago

Replying to ryan:

Setting the execute bit on directories makes sure dir listing and traversal is allowed.

'Doh, I forgot that :)

D

comment:38 @DD327 years ago

Theres problems on hosts where FTP is locked to certain directories.

Eg. ABSPATH = /home/dd32/blah/dd32.id.au/wordpress/
Root directory of FTP = blah/dd32.id.au/wordpress/ (/home/dd32 is not accessable or visible, it appears as /)

In those cases WP attempts to use ABSPATH to prefix the access attempts, It should rely on $wp_filesystem->find_base_dir() - I'm just debugging a bit here on a Dreamhost account.

@DD327 years ago

comment:39 @DD327 years ago

attachment 5586.3.diff added.

  • Respect FTP root folder,
  • Silence a few warnings(Auth. failed, using SSL when SSL not supported by FTP server
  • A string not __()'d correctly(Contained the URL in the translatable string, instead of a placeholder)
  • Change the ftp_chdir() function to work as expected(Return value cannot be trusted on certain setups, Need to check the working directory is the same)

comment:40 @ryan7 years ago

(In [7155]) wp-fs fixes from DD32. see #5586

@DD327 years ago

Better WP location search / Allow blank files in installer

comment:41 @DD327 years ago

attachment 5586.4.diff added.
Better WP location search / Allow blank files in installer

  • A better search for the base FTP directory, Now works for windows servers :)
    • Needs to be modified still, Should search for higher directories before jumping back to / straight away, Also needs a Loop prevention counter added (At present, if somethings gone wrong, it loops 100 times until PHP cuts it off)
  • added a missing chdir() method to ftpextension
  • allowed blank files to be installed, Presently if a blank file is attempted to be copied, it fails assuming it couldnt retrieve the file.

Slowly getting there, If anyone has issues, Install this plugin: http://dd32.id.au/files/wp-filesystem-tester.zip And give it a test run, I'd appreciate it if you can send the report along to me at wordpress@…

Also, Anyone who used the upgrader and it failed before [7155] needs to check their FTP directory for a /home/username/blah folder, and delete it if it shouldnt be there, Its causing the Wordpress location search code to fail (rewrite should take into account that folder may exist, even though it shouldnt be there)

comment:42 @ryan7 years ago

(In [7164]) wpfs fixes from DD32. see #5586

@DD327 years ago

Fatal Error fix

comment:43 @DD327 years ago

attachment 5586.5.diff added.
Fatal Error fix

To fix:

Fatal error: Call to undefined method WP_Filesystem_ftpsockets::chdir() in .../wp-admin/includes/class-wp-filesystem-ftpsockets.php on line 101

Forgot to include the chdir() function in the FTPSockets class

comment:44 @ryan7 years ago

(In [7171]) ftpsockets fix from DD32. see #5586

comment:45 @DD327 years ago

Just had a report that the upgrader deleted the entire /plugins/ folder, rather than just a subfolder.

However, They cant reproduce, nor can i:

11:55	aaronjj	hmm... tried to auto-upgrade a plugin and it deleted my entire /plugins/ folder.
11:56	DD32[a]	aaronjj: was the plugin in a folder? Or simply in /plugins/ ?
11:57	aaronjj	it was in a folder. it was the wp db backup plugin. I've been trying to recreate the error and everything is working fine now
	aaronjj	DD32: it failed on the last step
11:58	aaronjj		DD32[a]: using latest trunk downloaded from wp.org

		DD32[a] changes nick to DD32
11:59	DD32	Hm, Allright, Can you install this plugin, http://dd32.id.au/files/wp-filesystem-tester.zip activate it, and then send me the details from its page to wordpress@dd32.id.au ? I'd just like to check theres not a case i've missed
	aaronjj		DD32: sent. note that when the upgrade failed it left the /wp-content/upgrade/ folder behind with the new version of wp-db-backup

	DD32	allright, Thanks, i'll have a look at it and see if i can spot anything
12:09		-> TelnetManta has joined wordpress
12:11	DD32	aaronjj: hm, That all looks perfect to me. It doesnt supprise me that it worked afterwards, why it failed first time 'round.. I'm not quite sure
12:12	aaronjj		DD32: has that been an issue in the past? losing the entire /plugins/ folder?

12:13	DD32	aaronjj: Its happened to me once, but i caught the reason for it, and the current upgrader is designed to catch the cases where it attempts to delete the entire plugins directory

However, I think there needs to be some extra checks that the folder its going to delete is valid, checking if its '.' or the main plugins directory aparantly doesnt work 100% (Else this person wouldnt've lost the entire directory).
maybe a preg_match('|' . PLUGINSDIR . '/(.+)|') to make sure theres something after the plugins directory?

Attaching a patch to raise an error if WP comes up against the problem that it cant locate a valid WordPress folder. (Unrelated to this problem, But if it cant locate the correct folder, it certainly shouldnt continue attempting to follow through)

@DD327 years ago

@DD327 years ago

comment:46 @DD327 years ago

attachment 5586.7.diff added.

Patch makes show_message() show any error data which was passed through to it.

Its useful in debugging issues where the Zip class cannot handle a zip file. Eg:

Before:
Incompatible archive
After:
Incompatible archive: Unable to find End of Central Dir Record signature

It will hopefully allow testers & users to report back the bugs which they come accross, "Incompatible Archive" is really a rather bland error to debug from.

Also, I've been told that the OneClick plugins zip routines DO work on a host that recieved that "Incompatible Archive" message, So looking at that plugin, Heres the code its using:

        if ($archive->extract(PCLZIP_OPT_PATH, '../wp-content/plugins/') == 0)
        {
            if (function_exists('exec'))
            {
                exec("unzip -d ../wp-content/plugins/ ../wp-content/plugins/oneclick/$uploadedfile");
            }
        }
    }

My guess is that its falling back to the unzip program in the case where PclZip was failing - I dont like the idea of using exec() though.

comment:47 @ryan7 years ago

(In [7205]) Return error if base dir empty. Props DD32. see #5586

comment:48 @ryan7 years ago

(In [7206]) Show error data in message. Props DD32. see #5586

comment:49 @mark8barnes7 years ago

  • Severity changed from normal to critical

I just had my entire plugins folder deleted too. FWIY I was trying to update the Google Analystics plugin. Using 10 March nightly.

comment:50 @DD327 years ago

I just had my entire plugins folder deleted too.

Heres where Unit tests would've been good.

PLUGINDIR doesnt have a trailing slash.. well, it shouldnt at least. Currrently it will delete the entire contents of the plugins folder if you attempt to upgrade a plugin which exists as a single file inside of wp-content/plugins/

Attaching patch.

@DD327 years ago

Critical: updater deletes entire plugins folder if upgrade a plugin which exists as a single file.

comment:51 @DD327 years ago

If people want to throw me debug information if something goes wrong, You can install this plugin, and then send the debug page info over to me: wordpress@…

http://dd32.id.au/files/wp-filesystem-tester.zip

comment:52 @ryan7 years ago

(In [7209]) Fix deletion of plugins not in their own directory. Props DD32. see #5586

comment:53 @ryan7 years ago

  • Severity changed from critical to blocker

comment:54 @matt7 years ago

I can confirm that all my plugins were deleted, including custom ones. :(

comment:55 @mark8barnes7 years ago

This last diff is an improvement, but it's not foolproof.

I tested it with a plugin that was a single file in the plugins folder. But the update was multiple files in a subfolder. (Not a common scenario, but one that could be duplicated on other installations.)

The update mechanism deleted the first folder in my tree (which was nothing to do with the plugin I was updating), left the original file behind, the copied the new updated plugin.

comment:56 @mark8barnes7 years ago

As a total separate issue to do with this update, shouldn't we be using type="password" in the FTP login screen.

comment:57 @DD327 years ago

can confirm that all my plugins were deleted, including custom ones. :(

Was that before or after the last commit?

I ran a file-recovery software over my local computer when i managed to delete all the plugins.. there was a reason i stressed backups on the testers list..

This last diff is an improvement, but it's not foolproof.

Agreed.

I tested it with a plugin that was a single file in the plugins folder. But the update was multiple files in a subfolder.

Thats *VERY* common, infact, thats how all plugins coming from wordpress.org will be installed, into a subfolder, even if theres only one file in it.

Actually, Now its morning, Something has poped out at me, and i'm wondering why its not being used instead..

$plugin_file = akismet/akismet.php || hello.php
if( strpos($plugin_file, '/') > 0 )
//Dir
else
//File

or even:

if( empty(trim(dirname($plugin_file), '/')) )
//File
else
//Dir

I think there may've been a reason why this wouldnt work, But i honestly cant see one?

Its much more reliable than checking to see if the working directory is not the plugins folder, And with the adition of the error if the WP base is not found, it should never come accross the wrong folder..

While i'm at it, Should WP be running a hook for plugins to link, so they can tell if their plugin has been upgraded? What about running Deactivation, followed by Re-activation? (Exept.. i guess unless it did a redirect, or a iframe, it'd still be running the old plugin at that point)

shouldn't we be using type="password" in the FTP login screen.

Probably, With autocomplete="off", it'll invalidate the html i think, but better to block IE from saving it.

@DD327 years ago

comment:58 @DD327 years ago

attachment 5586.9.diff added.

I'm not sure why its not showing the HTML preview, I tried re-creating and re-uploading it, but still no dice.

Changes:

  • Minor typo corrections in the Filesystem abstraction
  • If the FTP details entered do not work, then the message: "Error: There was an error connecting to the server, Please verify the settings are correct"
  • PclZip's Incompatible Archive message now includes the error code, eg: PCLZIP_ERR_BAD_FORMAT (-10) : Unable to find End of Central Dir Record signature
  • Enabled nonces on the plugin upgrade, the nonce is plugin-upgrade-$plugin
  • Removed some cruft
  • Changed the plugin directory delete condition: Its now checking to see if a '/' exists within the plugin basename.. If a slash exists, its within a folder, and that folder will be deleted. It also checks that the dir is NOT the plugins folder specifically, but that has shown to slightly unreliable
  • Oh, Also s/"/'/ on strings in the update function where not needed.

comment:59 @mark8barnes7 years ago

I'm not able to test this right now, but one extra thing I forgot to mention. An earlier post said: "To upgrade via FTP, you need to define FTP_HOST, FTP_USER, and FTP_PASSWORD in your wp-config.php".

Has this been replaced by the log-in screen? I for one would appreciate being able to specify this globally.

comment:60 @ryan7 years ago

(In [7238]) Auto update fixes from DD32. see #5586

comment:61 @DD327 years ago

Has this been replaced by the log-in screen? I for one would appreciate being able to specify this globally.

I believe so.

Being able to specify a global option is fair enough, However, i'm not sure how many people would want to hard-code a password?

How about this:
If FTP_HOST, FTP_USER, FTP_PASS, or FTP_SSL is defined, then that input box gets disabled, and the hard-coded default is shown.
If all required details are hard-coded, then it skips showing the dialogue at all.
In event that it fails to connect, The login prompt is shown again & hard-coded params show in the disabled fields (Minus the password, yet the field would also be disabled).

That'd allow for hard-coded defaults for whichever fields the owner wants to hard-code.

(Keep in mind that the ftp option does remember your Hostname and username selections allready)

comment:62 @ryan7 years ago

Optional defines are cool.

@DD327 years ago

Allow FTP details to be hard-coded

comment:63 @DD327 years ago

attachment 5586.10.diff added.
Allow FTP details to be hard-coded

Attachment allows for things such as this in wp-config.php:

define('FTP_HOST', 'localhost');
define('FTP_USER', 'dd32');
define('FTP_PASS', 'dfsdf');
define('FTP_SSL', false);

You can define as many, or as few as wanted.

  • If a field has been define'd, then the input field on the dialogue will be disabled, and the hard-coded value displayed.
  • Upon an error connecting, The dialogue will be shown, However, All defined fields will remain disabled.
  • The password field never has a value filled in, even upon an error connecting, or a defined password, So as to not leak the password via the web interface (and potentially end up stored in a cache somewhere)
  • In the case of the FTP Password being define'd & an error occurs causing the dialogue to be shown, The field remains disabled and will be empty(even though the password is defined), and a note is shown beside the field: _e('<em>(Password not shown)</em>');
  • If ALL details are define'd, and an error occurs while connecting, The user will be directed to the ftp credentials dialogue with all fields disabled, but may attempt connecting again via the Proceed button, If the details are wrong, then the defines will need to be corrected, under no circumstances can the web form override the defines.

comment:64 @dougal7 years ago

I've seen an issue several times when using the plugin updater where I get zero-byte files.

The update appears to work fine, I get normal status messages (Downloading, Unpacking, Removing old version, Installing the latest version, Plugin upgraded successfully), but when I check the actual plugin directory, some files are empty (zero bytes). I haven't seen any pattern to which files. But obviously, depending on which file it is, that will tend to make the plugin unusable.

And, if you didn't deactivate the plugin first, this can immediately kill your site, forcing you to scramble to do an emergency manual plugin update. That could probably be mediated by automagically deactivating/reactivating the plugin as part of the update process.

Anybody else seen this? What debug info can I provide to help add some error handling?

  • PHP 5.2.1
  • Apache 1.3.x
  • WP SVN revision 7266
  • FreeBSD
  • libzip 0.7.1
  • PHP Zip version 1.9.0

On another note, when doing an upgrade, it's a little disconcerting to have the page go blank for a long time while it's downloading files and such. Could we add some flush() calls in there so that the browser updates along the way, and the user can see progress being made?

comment:65 @dougal7 years ago

  • Cc dougal added

comment:66 @dougal7 years ago

  • Keywords ftp zip updater added

comment:67 @ryan7 years ago

(In [7297]) Allow hardcoding of FTP connection info. Props DD32. see #5586

comment:68 in reply to: ↑ 25 @westi7 years ago

Replying to DD32:

Just a quick note.
I'm having troubles with PclZip on a certain server with the archives from wordpress.org I've not tested many, but exact same script & file works locally, Yet fails on the server.

The issue is happening around like 4595:

$v_bytes = ($v_bytes << 8) | Ord($v_byte); 

Completely different results between my local system (AMD64 X2 + XP 32bit SP2 + Apache 2.2+ php5.2.4), and the server (Linux creep 2.6.16.1 #3 SMP Sat Apr 1 16:37:28 WST 2006 x86_64 GNU/Linux + Apache + PHP 5.0.5-2ubuntu1.8 & PHP 4.4.0-3ubuntu2)

I'm no good at bitwise maths, So i'm unsure whats happening..

Hopefully fixed in [7314] for #6236 will send upstream once I have feedback on it improving things.

comment:69 @DD327 years ago

See also: #6245 for incompatibilities with specific FTP server setups.

@DD327 years ago

comment:70 @DD327 years ago

5586.11.diff (1.0 kB) - added by DD32 on 03/18/08 04:05:11.

Add Nonce explanation.

comment:71 @ryan7 years ago

(In [7377]) Add explanatory text for upgrade plugin nonce. Props DD32. see #5586

@DD327 years ago

comment:72 @DD327 years ago

attachment 5586.12.diff added.

  • Typo in the ftpext class
  • Safe mode kicks in and prevents opening of the file if its using /tmp/

Errors like this:

Warning: fopen(): SAFE MODE Restriction in effect. The script whose uid is 10205 is not allowed to
access /tmp/wpupdateWI7gv2 owned by uid 48 in /var/www/vhosts/.../httpdocs/wp-
admin/includes/file.php on line 206
Warning: fopen(/tmp/wpupdateWI7gv2): failed to open stream: Permission denied in
/var/www/vhosts/.../httpdocs/wp-admin/includes/file.php on line 206

This will cause the pdate page to read as "Download Failed" because its failed to find a useable directory.

In cases like that, The blog owner can define WP_TEMP_DIR to point to a directory where PHP CAN write files. (Note: It checks to see if it can write to /wp-content/ and uses that before it relies on the systems directory, or /tmp/)

comment:73 @ryan7 years ago

(In [7393]) Fix typo in ftpext class. Handle safe mode errors. PRops DD32. see #5586

comment:74 @djr7 years ago

  • Cc djr added

comment:75 @DD327 years ago

In cases like that, The blog owner can define WP_TEMP_DIR to point to a directory where PHP CAN write files. (Note: It checks to see if it can write to /wp-content/ and uses that before it relies on the systems directory, or /tmp/)

I was just wondering if its worth checking for the PHP upload folder in cases like that too? Or under safe mode, is that useless too? I dont deal with safe_mode often.

ini_get('upload_tmp_dir');

comment:76 @ryan7 years ago

(In [7403]) Check return of tmpfile(). see #5586

@DD327 years ago

comment:77 @DD327 years ago

attachment 5586.13.diff added.

Probably time to let it choose the best connection method, Theres no real bugs turning up with ftpsockets so far, And anyone who's so far had troubles would probably work with either the Direct or FTP Extension methods.

@DD327 years ago

comment:78 @DD327 years ago

Ryan: (In [7414]) Enable wpfs auto selection. Props DD32. seee #5586

attachment 5586.14.diff added.

Some Direct FS fixes. connect() needs to return true.
I'm not sure why returning a empty array doesnt work for request_filesystem_credentials, i tried to find the cause, But i couldnt see anything wrong at all. returning true does work though.

comment:79 @ryan7 years ago

(In [7415]) wpfs direct fixes from DD32. see #5586

@DD327 years ago

Support certain Dedicated server setups.

comment:80 @DD327 years ago

attachment 5586.15.diff added.
Support certain Dedicated server setups.

  • Certain setups where the FTP CWD is /home/username/ yet WordPress is installed in /var/www/..../ are having difficulties.
  • If the install cannot be located at all, switch it back to root /, Enable a loop flag so that it doesnt get stuck in a loop if i cant find WP.

comment:81 @ryan7 years ago

(In [7443]) FTP find_base_dir fixes from DD32. see #5586

@DD327 years ago

Return WP_Error from download_url() on HTTP Errors

comment:82 @dougal7 years ago

FYI, I just tried updating a pretty large plugin (wp-openid), and it seems to have succeeded with all files intact. Don't have time for in-depth testing right now, but that looks like a good sign to me :)

@DD327 years ago

includes changes from download-url-wp_error.diff

comment:83 @DD327 years ago

attachment 5586.16.diff added.
includes changes from download-url-wp_error.diff

Fixes:

  • HTTP Error on Package downloads causing invalid Zip errors
  • Cases where current plugin filename differs from the WordPress.org slug

@DD327 years ago

add missing(yet unused by WordPress) method chdir() in Direct FS wrapper

comment:84 @ryan7 years ago

(In [7547]) Return WP_Error from download_url() on HTTP Errors. Fix cases where current plugin filename differs from the WordPress.org slug. Props DD32. see #5586

comment:85 @westi7 years ago

  • Milestone changed from 2.6 to 2.5
  • Resolution set to fixed
  • Status changed from new to closed

Close this as we have now released.

Please raise new tickets for new issues.

comment:86 @lloydbudd7 years ago

  • Summary changed from Auto installer for themes and plugins to One click plugin updates

Change misleading title from
Auto installer for themes and plugins
to
One click plugin updates

Note: See TracTickets for help on using tickets.