[wp-trac] [WordPress Trac] #10522: timeout for ftp connections as a constant in config.php

WordPress Trac wp-trac at lists.automattic.com
Tue Oct 6 23:20:56 UTC 2009

#10522: timeout for ftp connections as a constant in config.php
 Reporter:  ntm           |        Owner:  dd32  
     Type:  defect (bug)  |       Status:  closed
 Priority:  normal        |    Milestone:  2.9   
Component:  Filesystem    |      Version:  2.8.2 
 Severity:  normal        |   Resolution:  fixed 
 Keywords:  has-patch     |  

Comment(by Denis-de-Bernardy):

 Replying to [comment:26 dd32]:
 > > wp-admin/includes/file.php
 > That is defined as a per-action timeout, Not as a entire connection

 we probably need an extra define, then, so as to allow plugins to bump it
 to something very large if needed without affecting direct and SSH

 > > wp-admin/includes/class-wp-filesystem-ftpsockets.php
 > The timeout in that file is on a per-action basis, Setting the
 FS_TIMEOUT value that high in that class is only ensuring that actions
 will only time out after a long time.
 > > wp-admin/includes/class-wp-filesystem-ftpext.php
 > Typo is a valid bug, And increasing it to 300 might solve some peoples
 problems, Comment changes are not - They're defaults for the class, and
 its a per-ftpext thing, not a ftp thing.

 Are you 100% on this? I ask, because my FTP software (on my desktop)
 frequently reconnects during WP uploads. To me, it's an FTP thing, rather
 than an ftpext thing.

 Also, it's worth noting that, on Dreamhost, doing the following shell
 command can time out:

 for site in `ls */wp-config.php`; do site=${site%%/*}; cp -R wordpress/*
 $site/*; done

 You end up losing the SSH connection with enough domains.

 > A better solution is to send a NOOP or similar keep-alive during
 extracion every 15s or so, I've got some code around here which will work
 on 2.9+, I'll just have to dig it up.

 That would totally rule, if we could keep the bloody thing alive. note,
 however, that some servers force the maximum time out and disallow to
 override it. I can't recall which host I saw this occurring on, but I do
 remember telling the customer to change host precisely because of this.
 Disconnect + reconnect was the only reliable workaround, but I couldn't
 achieve that in some areas (namely unzip_file()) due to the lack of plugin

Ticket URL: <http://core.trac.wordpress.org/ticket/10522#comment:27>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software

More information about the wp-trac mailing list