A few days ago, it was brought to my attention that something had been broken on the PHP-GTK community site during the 5.0 RC2 upgrade. The problem was easily identified as being codefilter.module having been removed during the upgrade and not reinstalled. Of course, not being at my office, I did not have access to the FTP passwords, but just to my admin account, and I did not want to leave the community members in the cold, so I used this small trick.

1. login to the site with a privileged account, allowed to make use of devel.module
2. grab the module from drupal.org
3. enable the Execute code block from Devel
4. edit some node, no matter which
5. attach the module files to the node being edited, not listing them
6. in the Execute code box, use commands like the following, one at a time to make sure all goes well (typos !). Supposing your files directory is named "files" under the site root:
   1. First, a check to make sure everything is where it's supposed to be:
      system('ls -l files sites/all/modules');
   2. Then create the module directory:
      system('mkdir sites/all/modules/codefilter');
   3. Then copy the files over to it:
      system('cp files/codefilter.* sites/all/modules/codefilter');
7. detach the files from the node where you had attached them
8. the module is now there in your modules list, ready to be enabled.

As you can see, nothing spectacular, but it can come in handy when you're missing normal tools.

Note 1: this will probably only work differently when file transfers are set to "public", which is the default.

Note 2: I used cp instead of mv intentionally: this means the files won't move from the drupal files directory without drupal knowin g it, and they can be removed cleanly when you detach them from the node.