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.
- login to the site with a privileged account, allowed to
make use of
- grab the module from drupal.org
- enable the
Execute codeblock from Devel
- edit some node, no matter which
- attach the module files to the node being edited, not listing them
- in the
Execute codebox, use commands like the following, one at a time to make sure all goes well (typos !). Supposing your
filesdirectory is named "files" under the site root:
- First, a check to make sure everything is where it's supposed
system('ls -l files sites/all/modules');
- Then create the module directory:
- Then copy the files over to it:
system('cp files/codefilter.* sites/all/modules/codefilter');
- First, a check to make sure everything is where it's supposed to be:
- detach the files from the node where you had attached them
- 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
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.