Posted by Reg on March 17, 2010 at 3:15am
| Project: | Spamicide |
| Version: | 6.x-1.3 |
| Component: | Code |
| Category: | bug report |
| Priority: | critical |
| Assigned: | Unassigned |
| Status: | closed (fixed) |
Issue Summary
It took me a while to track this down because the first thought when files don't copy etc. is it's a permissions problem. However, I can remove my files/css dir., change some colors in garland, save, and the directory gets recreated.
On the other hand, the files/spamicide directory never gets created and spamicide won't work unless I create it first.
On tracing the called in spamicide to file_save_data() which ends up calling file_copy() here's what I see:
Garland's call to file_copy():
file_copy dest passed: sites/mysite.com/files/css/css_c8c07c43f319644ab6c83fc4d3fd656d.cssSpamicide's call to file_copy():
file_copy dest passed: spamicide/afile.cssSo spamicide needs to do whatever Garland does to take into account multisite paths and then all will be well. Sorry I haven't figured out what that is but I figure it's probably a trivial step with the above now figured out.
Comments
#1
This bug report is actually a 2-in-1. :-)
1.) CSS files are created at the wrong path.
To fix this, replace this:
file_save_data($css, $css_file, FILE_EXISTS_REPLACE);with this:
file_save_data($css, $path, FILE_EXISTS_REPLACE);in the spamicide.module file in the
_spamicide_set_css_file()function.2.) The "spamicide" directory is not automatically created.
It is, but only upon visiting the
admin/reports/statuspage of your Drupal site.The problem is that the check for the existance of the directory (and automatic creation) is only in spamicide.install/spamicide_requirements() and not in spamicide_install().
The above observations are true for v1.2 of the 6.x branch.
#2
Altered the title to better match the actual problem and changed priority to critical since the module does not work at all without having the directory created.
#3
Changed the status to "needs work", because I didn't provide patch for the spamicide.install problem (it kinda obvious and visiting the status page was an adequate workaround/quick-fix for me).
#4
I've found that there're lots of issues with v1.2 release (for Drupal 6.x) that prevent out-of-the-box use of the module.
Eg. a bug (not yet reported here) is in logging. If you already have a log entry from this module in your watchdog, then loading the
admin/reports/dblogpage will generate twophperrors:1.) Invalid argument supplied for foreach() in /home/www-data/wmuzso/www/includes/common.inc on line 924.
2.) strtr() [function.strtr]: The second argument is not an array in /home/www-data/wmuzso/www/includes/common.inc on line 941.
The cause: spamicide.module contains a Drupal v5.x style
watchdog()call which places the "i:5" value in the "variables" field of the watchdog table and theadmin/reports/dblogpage expects a serialized array. The fix is to replace the followingwatchdog('Spamicide',t('%form_id post blocked by Spamicide module: their IP address is "%ipaddress".',
array('%form_id' => $form_id, '%ipaddress' => $_ENV['REMOTE_ADDR'])
),
WATCHDOG_NOTICE);
}
with
watchdog('Spamicide',t('%form_id post blocked by Spamicide module: their IP address is "%ipaddress".',
array('%form_id' => $form_id, '%ipaddress' => ip_address())
),
array(),
WATCHDOG_NOTICE);
}
You might have noticed that I replaced the reference to
$_ENV['REMOTE_ADDR']with a call to the functionip_address(). In my setup the$_ENV['REMOTE_ADDR']variable is not defined ($_SERVER['REMOTE_ADDR'] is defined and contains the expected client IP address, but ip_address() is meant to be used here ... the corewatchdog()function uses it anyway).If you already have erroneous entries in your watchdog, then either manually remove those records (the records where type = 'Spamicide') or clear the entire watchdog table (the latter can be done through the UI too, the former only by running a proper "delete" SQL statement on the table).
#5
To make life of first time users simple, I've created a patch that includes my fixes described in this bug report and other fixes from the following bug reports:
I've also attached the patched module (complete tgz because "*.module" files are not allowed here) so that people not knowing how to use a patch can have the bugfix version too.
#6
FWIW - On my site with spamicide 1.2 installed the "To prevent automated spam submissions leave this field empty" field was visible. I created the files/spamicide directory manually, then looked through the patch in #5 and found that most of the changes in that patch were already present (except for the following), so I applied the following change. That still didn't make the field invisible, so I went to performance settings, disabled CSS aggregation, and then the field became invisible. I reenabled CSS aggregation and the field is still invisible.
diff -r b4e96c917c77 sites/all/modules/spamicide/spamicide.module--- a/sites/all/modules/spamicide/spamicide.module Tue Apr 27 12:41:59 2010 -0700
+++ b/sites/all/modules/spamicide/spamicide.module Tue Apr 27 12:44:31 2010 -0700
@@ -425,7 +425,8 @@
$path = file_create_path($css_file);
if (!file_exists($path)) { // or !is_file or !file_exists or !file_check_location
$css = "#edit-". str_replace('_', '-', $form_field) ."-wrapper\n{\n display: none;\n}\n";
- file_save_data($css, $css_file, FILE_EXISTS_REPLACE);
+ //file_save_data($css, $css_file, FILE_EXISTS_REPLACE);
+ file_save_data($css, $path, FILE_EXISTS_REPLACE);
}
}
#7
That's pretty strange. I've rechecked my previously submitted patch.
Downloaded the _official_ 6.x-1.2 version of Spamicide from http://ftp.drupal.org/files/projects/spamicide-6.x-1.2.tar.gz, created a diff between the spamicide.module in that tar.gz and the spamicide.module in my patched version (that I've attached to #5 comment in this post) and the result was the same patch file that I've also attached to #5 comment.
So the only conclusion I can make of this is that your 1.2 module must have been a development version of the already released 1.3 version (I don't know that for sure yet, because I've not yet tested v1.3 whether it has all the patches applied or not).
#8
Solution #1 and #4 still not fixed in v1.3 (final).
#9
Patched module file v1.3. Fixes issues #744560: Installation does not create required directory and CSS is saved in the wrong path, #722014: Spamicide seems to install and configure OK but doesn't prevent spam in any form!!!!, #465100: "recoverable fatal error" with fix.
(Was there a change between v1.2 and v1.3 at all? The file date of the module is still from 2009.)
#10
You have to apply the modification from #1 also to line 426 of the patch from #9.
#11
@ #1 2)
This could be amended by changing
$phase == 'runtime'to$phase == 'install'in spamicide.install:http://api.drupal.org/api/function/hook_requirements/6
EDIT
Doesn't seem to work on first try. Also, uninstall() should remove the spamicide directory.
#12
See also #955326: Faulty CSS created when renaming fields.
#13
I've fixed these issues, please try the latest stable release.
P.S. working on adding features to totally hide spamicide's signature such as renaming the directory and changing the description.
#14