Installation does not create required directory and CSS is saved in the wrong path

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/status page 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.

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.

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).

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/dblog page will generate two php errors:
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 the admin/reports/dblog page expects a serialized array. The fix is to replace the following

watchdog('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 function ip_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 core watchdog() 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).

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:

• http://drupal.org/node/465100
• http://drupal.org/node/722014

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.

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);
   }
 }

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).

Solution #1 and #4 still not fixed in v1.3 (final).

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.)

You have to apply the modification from #1 also to line 426 of the patch from #9.

@ #1 2)

This could be amended by changing $phase == 'runtime' to $phase == 'install' in spamicide.install:

This hook has two closely related uses, determined by the $phase argument: checking installation requirements ($phase == 'install') and status reporting ($phase == 'runtime').

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.

See also #955326: Faulty CSS created when renaming fields.

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.