On IRC, Károly Négyesi (better known as chx) asked me about the status of the Drupal FTP project. He was concerned that it stores FTP usernames and passwords, which could open up the possibility for security holes and malware if extended or used improperly. Additionally, one of its stated goals was as a possible means to automatically download and install modules on one’s site, which is also a stated goal for the Plugin Manager Summer of Code project.
At first, I said that I would remove the project entirely, as I hadn’t worked on it in over a year, and had no intention of continuing development in the near future. Even at that time, although I saw the possibility for using it to install modules on your site, I wasn’t really that interested in pursuing that aspect, as I really didn’t want to get into the security issues involved.
However, I decided to post to the Developer’s list first, to get further feedback before removing the project. I had had a few queries regarding the project over the past year, and suspected that there might be some developers actually using it. Additionally, I wanted to find out if there were any compelling reasons to actually keep the module in the project repository.
Turns out to have been a good thing, it looks like. Not only are there a few people actually using the module, I was reminded of other efforts to use FTP with Drupal, most notably Media Mover and, of course, the upcoming Plugin Manager module.
Arthur Foelsche (arthurf), a creator and maintainer of Media Mover, suggested that we might want to create an API for use with other modules, specifically because of the security concerns of maintaining such a system, and the multiple uses for it.
Victor Kane chimed in with the suggestion of examining Joomla’s callback method, which place’s a site’s FTP info in the database, requiring a push from the Drupal side.
Additionally, Dave Cohen mentioned that the Upload API contrib module could have an add-on that could detect FTP-uploaded files and insert them into the system. (Similarly, the Asset module could do the same thing.)
Finally, FGM states he has an FTP client driven by an external state machine that can conduct batch operations with progress displays (not developed as a module, but designed for PHP-GTK).
Thomas Zahreddin also suggested we look at the Advanced FTP client class as a better engine for the internals.
Basically, after all this feedback, I think it’s best to not throw in the towel for Drupal FTP. I believe we should all get together and map out the best form such an API might take. We could start with FTP support, but if we took the long view, we might want to support or add other ways of moving files remotely, such as sftp. With that in mind, the original plan for File API might be a better place to work from.
In any case, it’s definitely time to form a working group for this. I’ll post later this week with some thoughts for a road map for a plan of action. This is definitely a place where having some cooperation between seemingly disparate modules can go a long way.