Closed (won't fix)
Project:
Spam
Version:
5.x-1.x-dev
Component:
Code
Priority:
Minor
Category:
Feature request
Assigned:
Reporter:
Created:
14 Sep 2007 at 17:32 UTC
Updated:
24 Apr 2008 at 16:45 UTC
This patch provides an uninstall hook for the Spam module and cleans up some stuff that appears to have been for testing.
| Comment | File | Size | Author |
|---|---|---|---|
| spam_inst.txt | 5.63 KB | nancydru |
Comments
Comment #1
anarcat commentedI'm not sure it's appropriate to package whitespace changes in such a patch, keep whitespace changes seperate.
Also, maybe the DELETE on the variables table should be more selective, and explicitely list the used variables instead of destroying on such a wide pattern. Here's the variables I could find from the code:
$ grep variable_.et spam.* | sed 's/^.*variable_.et(\([^,]*\),.*$/\1/' | sort -u
"spam_filter_$content->type"
"spam_filter_$node->type"
"spam_filter_$type"
'site_mail'
'site_name'
'sitename'
'spam_blacklist_ip'
'spam_default_probability'
'spam_display_probability'
'spam_display_quantity'
'spam_duplicate_content'
'spam_email_timer'
'spam_expire_time'
'spam_filter_comments'
'spam_filter_urls'
'spam_flush_log_timer'
'spam_interesting_tokens'
'spam_ip_filter_sleep'
'spam_log_level'
'spam_notify_admin'
'spam_notify_user'
'spam_report_feedback'
'spam_threshold'
'spam_unpublish'
'spam_urls_repeat'
'spam_urls_total'
Comment #2
nancydruYes, I thought about doing it that way, which is what I usually do. However, "spam_filter_$type" is a variable and occurs for each content type. I didn't want to have to go through some content type table somewhere just to do individual variable_del's. The only variables I see in my table that start with "spam_" belong to this module.
'site_mail', 'site_name', 'sitename' are not Spam variables. [And if you did find a "sitename" then he missed one...]
I did the whitespace because there was other clean up in that area.
Let's let Jeremy decide if the patch really needs work.
Comment #3
jeremy commentedAs with your other patch, my big complaint is that you're touching unrelated things (whitespace far away from where you're adding/modifying code).
This query is also unacceptable:
db_query("DELETE FROM {variable} WHERE name LIKE('spam_%%')")as it could inadvertently remove a setting from some other module. I will probably just merge the drop table portion of the patch, not the variable stuff or white space changes.
Comment #4
jeremy commentedI manually merged part of your patch, thanks. The variables still need to be handled cleanly. Probably the best thing to do is to use a big array, then walk through it one member at a time. A little more tedious, but will prevent accidentally removing unrelated settings.
Thanks!
Comment #5
jeremy commentedDevelopment is happening in the 3.x branch of this module. This issue will be addressed there.
Comment #6
nancydruAny idea when that will be ready?
Never mind, I see the alpha release. Guess I'd better get busy testing it.
Comment #7
jeremy commentedEventually. It's starting to be usable now, and I've deployed it on one of my smaller websites. The more I use it, the more I'll work on it...