This is a very important module.
Yes, I second that. I will try to get the porting started, but I don't really know which branch I should choose as a base. Drupal-5--3 is what seems to be the newest version of this module, but is it stable?
Also I will need some help in the porting progress. I think I'll post problems in this thread?
See comment #4 for more up2date code
I've ported both *.install files, the patches are attached. I've used the schema module, so I'm not sure all fields are the way they should be. Especially I'm not sure wether all those disp-width attributes are required.
Now I'm going to use the coder module and clean things up. The biggest obstacle would be spam_menu() since I'm not sure how to port the !$maycache part. http://drupal.org/node/103114 states:
Also code to be run once in D5 that was placed into hook_menu !$may_cache. Now you should use the somewhat new hook_init. Previously we called hook_init twice, once early in the bootstrap process, second just after the bootstrap has finished. The first instance is now called boot instead of init.
But the api doesn't talk about how to add menu items from hook_init(), is a simple return like in hook_menu() all I have to do? And is $type in path spam/$type/$id/action either spam or ham? And the $id is a content_id in the spam database. But is this a foreign node key? If so, why not rename it to nid?
see comment #4 for more up2date code
I've done more work, spam module is drupal 6 compliant and all coding standards are fullfilled (using coder module). You can activate the module and the spam filter, no warnings, no nothing. But I'm not sure if all works as intended. Also I wonder if this was the correct branch to work on.
I need more input from the maintainer!
I attach one bich patch with all changes and a tarball with the module, so people can test it.
NEGLECT WHATS WRITTEN ABOVE
This is the real deal. I've ported the latest dev-snapshot (http://drupal.org/node/106694) to Drupal 6. It seems to be working so far. I need more testers.
I might come across some issues myself, but the more tester the better. And since I've never used this module before, I need input from those who have. Regressions? Missing features? Missing menu links?
I'm particularly interested in the whole email related stuff, since that was the part which required the most new code. I've completely rewritten the mail functions but tried to keep the translatable strings. Since I'm debugging on localhost which - as far as I remember - cannot send mails.
I'll attach a patch and a tarball for those who like to test it.
I'd like to have a review on my patch. Especially the email parts, the hook_menu implementation and the database schema. Additionally I've added some notes (search for NOTE:) with questions that popped into my mind. Problematic parts are:
Line 498 and below: The message body uses some replacements. This should be merged with the mail function I've written (see function spam_report_notify_admin).
Line 1931 and below: Some big SQL query gets build here. Coder module complains about not using db_query replacements. So my question: Is this code safe? And is the generated SQL database independent?
File related: Do we need the modules folder with those empty spam_* files?
Hopefully this will work out, good night fellow Drupal lovers!
Thanks for the patches! Unfortunately I'm on the road for the next week, and unable to review them. I should have some time during the Drupalcon the following week, and will try and review then.
I just want to clarify:
The attachments to comments #2 and #3 should be neglected imo. They are based on CVS head which seems to be quite old code.
I found some bugs and refactored the mail code again. Updated patch and tarball are attached. I think it's pretty much working now!
This seems to work:
Still untested are:
PS: I'll be snowboarding the next week, thus my answer will take time. But please review and test this code.
The patch does not seem to be against the latest code (Drupal-5.x3.x-dev last updated 03 december 2007), but a year old code (Drupal-5.x-1.x-dev last updated 3 January 2007)
The patch fails to apply to the newer branch. (103 out of 104 hunks failed)
(you probably knew that, but I thought this was better than just writing "subscribing" :D)
Anyway, enjoy you snowboarding.
Yes, I am aware, that I did not use Drupal-5.x3.x-dev. Instead I've used spam 5.x-1.x-dev (see http://drupal.org/node/106694), which was last updated on November 29, 2007. I did so because the newer version does not seem to be in a working state. See also the README.txt in http://ftp.drupal.org/files/projects/spam-5.x-3.x-dev.tar.gz
This is a complete re-write of the spam module. It is currently not usable.
This is a complete re-write of the spam module. It is currently not usable.
So please apply my patch to 5.x-1.x-dev instead and start testing it. I've already got a positive feedback via my website.
heh, colour me stupid. I was assuming that for some reason that branch was last updated in 2006! (and outdated by the actual 1.1 release ) - which it is not.
I will test this later on.
@milianw - regards the "!$may_cache" not above: What they were trying to say is things like "drupal_add_css" that used to be in that section should now be moved to "hook_init." AFAICT there is no equivalent section for real menu entries, but it is possible to use "hook_menu_alter" or "hook_menu_link_alter." I have not used either of those hooks yet. In the one case where I needed to alter the menu, I just included a line to clear the menu cache.
Also, now that a patch is available, I don't think this should be "critical" any more.
I just browsed your code. Anyone who looks at this patch might just get a better feeling about what it takes to make a major Drupal upgrade happen. Thanks for doing this.
I would like to see some "description" elements added to the schema, but this is really minor. And I don't think "disp-width" does anything; I really don't know what it is for. I've left it out of most of the modules I've converted.
Thanks for your response nacyw. Afair I've had the "!$may_cache" problem with the unstable spam branch. Starting with response #4 I've used a stable spam branch and thinks worked fine there. also see response #9. Hope you've looked into the code from post #7.
And to the "disp-width" - I think it's what the coder module proposed, I just copy'n'pasted there.
Just applied the tgz and patches in message #7 and got a SQL error.
user warning: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'em|texas holdem/i', 1, 0, 2, 0, 0)' at line 1 query: INSERT INTO spam_custom VALUES (2, '/casino games|poker online|texas hold\''em|texas holdem/i', 1, 0, 2, 0, 0) in /home/xxxxx/xxxxxx/xxxxxxx/modules/spam/spam.install on line 104.
On line 104 of spam.install, it seems to be missing a ( before the word casino. At least that fixed the MySQL error for me.
No I don't think there is a bracket missing but the escaping is wrong. The two slashes should be removed. I'll append a new patch and a new tarball.
Let me know if this fixes your problem.
Note: You don't need to apply the patch to test this module in D6. Simply grab the tarball and unpack it into your modules folder. The patch is for other developers to skim through and finally to apply it in SVN.
A patch against an older release of minimal use for actually getting this module ported to Drupal 6. The patch needs to be against current HEAD, and it needs to be updated as HEAD changes.
But current Head is unusable! And I for one _wont_ put any time into updating a _patch_ against changes in HEAD. No thank you. I'll stick to mollom.
milianw, thank you very much for all the efforts. So far, I can report only that I've just installed your latest version of the module without any problem.
In any case, the module - as is - doesn't appear on available updates list, as there are some entries missing in spam.info file.
I've added:version = "6.x-1.x-dev"
core = "6.x"
project = "spam"
datestamp = "1213955600"
to fix that.
I've also changed 'package = Spam' to 'package = Spam control', so Spam module now appears in 'Spam control' section, together with Captcha module (I hate to have too many additional - per module - sections...).
#18 Those fields are created by the release system and not needed in CVS or his Patch. With the possible exception of core = "6.x". The release system adds it in but I am not sure if it is still recommended to add that field or not?
@LUTi & rmiddle: core = 6.x is required for 6.x and above support.package = Spam control is used to group modules of a package (like Views, CCK, or Image) together. In this case, Captcha is probably using it incorrectly (unless it is composed of several separately installable pieces).
core = 6.x
package = Spam control
The other inclusions above are just wrong, as rmiddle said. Those are inserted by the packaging scripts. If you include them (particularly, the datestamp), you can thoroughly confuse Update Status and not know when new versions come out.
Having said that, I do believe that the existence of the Gotcha and Spam Tokens modules comes pretty close to justifying a "Package" parameter.
I personally see the monolithic 5.x-1.x branch of this module as a dead end. If you're interested in investing effort into the future of this module, I highly recommend you instead focus on the 5.x-3.x branch. I have deployed the 5.x-3.x branch on multiple live websites and found it to be more effective at blocking spam than the 5.x-1.x branch, and it also seems to consume less resources. Furthermore, it is better integrated into existing content management pages (particularly for comments).
I have no intention of ever creating a 6.x branch of the 1.x version of this module, as it would ultimately go totally unmaintained, resulting in problem reports and user frustration that would never get solved.
I would, however, welcome efforts to create a 6.x branch of the 3.x version. Ideally you'd first put efforts into helping stabilize the code base. Yes, there's more effort likely to be involved in trying to work on bleeding edge code, but it is working on the future of this module.
Would you please confirm that a copy of 5.x-3.x branch has been placed under HEAD. I would then like to help begin the migration of this branch to Drupal 6
The Drupal-5--3 branch seems to be the newest. I guess any porting would be off that branch.
I'd like to get a stable 5.x release of the 3.x version of the module before porting it to Drupal 6. Otherwise it just causes extra overhead on a project that I already have minimal time for. I estimate ~40 hours of effort to stabilize the 5.x version of this module.
Re-assigning this issue to the 5.x-3.x-dev queue, as that's the only version that will officially be ported to Drupal 6.
Updating issue status per version change.
It is a pity that the initial path from the old but working version was stopped.
Yes, this is open source and free, but why prematurely entrap someone to "leave the old version" only to learn that was a mistake?
For me the current "alpha" is nearly unusable, but the standard "update status module" does recommend only this "alpha" and explicitly asks to replace the older but working version. The upgrade did/does not work at all for me. Then a later backup to old version would overwrite the other changes in the db :(
If I guess from the current recognizable progress of the new module version (which I do not criticize!), a possible D6 version is available some time next year ...
I do not ask to work harder (yes, this is free), but I ask not to give false signals via update status module, and to positively tolerate a parallel path to temporarily advertise a D6 port of the old - even if explicit frozen (!) - version.
I respect the work, and I am willing support what I can do, but now this very spam modul is the single blocking point for me on 3 (soon 4) sites which I want to get to D6. I do not want to filter via external server (e.g. mollom) or captcha, especially as the "old spam module" did a good job for me.
I am only involved in "no-budget"-work, all sites are spare time tasks, so I am not prepared for funding anything. (The limited amount possible would not make a difference for the range of present tasks ...)
Can we restart a call to the port of the old (yes, frozen) version to D6?
I have zero interest in supporting the old version of the spam module. It became an ugly monolithic thing that proved far too painful to maintain. Thus, the only way forward as far as I'm personally concerned is to continue working on the 3.x version of the module. I'd love to finish it (there's about 40 hours of effort left), but I'm seriously lacking in spare time these days. It has stalled somewhat because it does everything I personally need it to at this time. If its incomplete status is negatively affecting so many of your websites, the best I can recommend is that you contribute some patches fixing the issues you've run into. If you don't have the time or coding ability to do that, then I recommend that you file very detailed bug reports so someone else is able to fix the problems you've run into.
BTW: As you have learned, the upgrade path was never completed. This is because some of the underlying logic is different enough that an upgrade path is far from trivial. I personally recommend you un-install the old 5.x-1.x version, and then install the newer 5.x-3.x version. Yes, you are then forced to re-train your filters, but you're going to have to do that anyway.
Thank you for your quick response, I combine both now:
> I have zero interest in supporting the old version of the spam module.
That's not the real problem. I have read your earlier postings here and think all was clear enough, sorry for repeating.
> I'd love to finish it (there's about 40 hours of effort left), but I'm seriously lacking in spare time these days. It has > stalled somewhat because it does everything I personally need it to at this time.
I do *not* argue to code faster! (but I do question "40 hours" ;-)
> the best I can recommend is that you contribute some patches fixing the issues you've run into. If you don't have the time or coding ability ....
> I personally recommend you un-install the old 5.x-1.x version, and then install the newer 5.x-3.x version
That I consider very bad. (Yes, I did 5.x-3.. for a part of the sites),
Not because of this:
> you are then forced to re-train your filters
Thats a minor annoyance and not the point I really complain about.
What If Drupal would officially withdraw a running version without accepted / running successor?
I do not ask *you* to spend time on the old version, but I do complain that you configured the versioning system to flag the (in my opinion only!) running version in the update status module to be replaced by the alpha version.
Why did you not manage to announce the development version and call the old one "frozen", announcing no more work for it, but *not* leading to prematurely replacing it?!
And that has yet nothing to do with D6. It is free, no one can ask you to do free work, but by "officially withdrawing" a running system without a suitable running sucessor (in my experience) I see you hurting your previous achievements,
Yes, i nevertheless try bug reports. but because of the failing upgrade script I have always first to try - what is the bug, what is possibly my fault and so on, there is a feeling of "no firm ground" for proceeding!
(there come in patches, fine and thanks, and I will look for some time to test them. But that is no routine task for me, sorry, and does not help for the real problem).
And for D6:
There was an offer to proceed with the old version to D6 by an other helpful coder, and this looked promising for me (Then, february, I was busy otherwise and not able to join in testing). You clearly state that you do not want to participate with this path, ok, of course accepted. But I hoped for the *independent* try for upgrading, unbundling your development stress from the path to D6.
You posted heavily against that, and so it was terminated - an that is bothering me. Why not let such an experiment flow freely, without obligation to you?
Ok - with your present standing this would be called a fork. I am not able to do such an effort. But with the actual "looking for a D6 version" I would happily try to support anybody who is trying to restart the stopped upgrade of the old spam module version to D6. You easily can take over when the new version is convincing everybody then.
With my normal spare time activity, I see no room for coding (I did never try a module myself). I try to suport Drupal by "evangelizing" it, helping others to use it. Now I am even tempted to retry coding for a D6 port 'of my taste' (especially as the new alpha is lacking a lot of features I liked with the old version), but that looks more like wishful thinking ;-)
At least you can consider my struggling for the spam module as a compliment to your previous achievements.
Still worried ,,, any help for a D6 spam module version including the old features in some sooner time out there?
There is a newer book in german about Drupal 6, sold printed, but free online (http://drupal.cocoate.com/de/node/1). There simply and valid just mollom and captcha is mentioned against spam.
"but I do question '40 hours' ;-)
What about it do you question? I'm reasonably confident of that estimate to get a first official release of this module out the door.
"I do complain that you configured the versioning system to flag the (in my opinion only!) running version in the update status module to be replaced by the alpha version."
This is a limitation of Drupal's project module -- I can either mark a release as supported or not supported. In this case, the 1.x release is _not_supported_, and thus you are told to upgrade. If I mark it as supported to address your concern, then the issue queue fills up with support requests and bug reports from users rightly assuming it is supported, wasting already insufficient time and further preventing the spam module from being finished.
Again, I suggest that the best thing you can do to help is to either 1) submit patches, 2) submit detailed bug reports that clearly explain how to duplicate each bug (one bug per issue), 3) fund the effort, 4) be patient.
I have deployed the 3.x version of the spam module on several sites, and it has worked much better for me than the old version, catching much more spam. I do not know when I'll find the time to complete the module, but it's fairly high on my todo list, and a port to 6.x would follow.
"What about it do you question? I'm reasonably confident .."
Sorry, there was a smiley.
"This is a limitation of Drupal's project module .."
This point was not clear to me, indeed. I still prefer it the other way.
"..and it has worked much better for me than the old version.."
I do not doubt this. For me too many of the old functions are missing.
I do not want to repeat, ok; meanwhile I hope for a parallel path, anybody there?
"For me too many of the old functions are missing."
Then you can help this effort by opening an issue for each missing feature. What features are important to you but are not yet in the 3.x version of the module? (Do not list them in this issue, they will just get lost. Instead, please open one new issue per missing feature.)
This has turned into a lengthy issue. I finally cleaned up the issue queue, clearly identifying the issues that need to happen before we have a beta release of the spam module. Once we're in beta, I consider the module reasonably stable and feature complete. Hopefully it will quickly be followed with a stable release, at which time it would make sense to focus on a 6.x port.
Postponing this issue until then. If someone is interested in tracking development and maintaining a 6.x patch against 5.x-3.x-dev, re-open and attach your patch. At that time I will contact you, and we could talk about opening a 6.x-3.x-dev branch.
What is the status? I see 5.x-3.x-dev has not been updated for awhile, so supposedly it is stable enough?
How far are we from getting this port done?
I'm interested too
Does anyone have time to work on this?
How far are we from 5.x-3.0 stable release? What are the remaining issues before 6.x port can start?
P.S. Marked "code needs work", based on this: http://drupal.org/node/222849#comment-851104
Can somebody re-upload the whole 6.x module with all fixed which has been made?
@kenorb: I think the latest posted is the one I linked to above... But apparently there have been many changes, including to schemas. I am total D6 newb and hope someone else could help get this upgrade started.
is it feasible to just switch to mollom ?
@paulbooker: Yes, if you are willing to pay for your spam. There has to be a fully FOSS alternative to solve the spam problem and at least a rigorous comparison. Besides even Mollom Plus has a usage cap...
I had to switch to Mollom because this module is so delayed and doesn't appear to be any where close to release. I agree there really needs to be a FOSS choice but I am way too busy to create one and since there hasn't been a commit in months (Oct 13th to Now Dec. 7) in the 5.x code not a lone a 6.x branch if things don't change Drupal 7 will be released before this module sees a Drupal 6 upgrade.
Mollom doesn't have a price on there site but they do have a support for accounts above Mollom Plus and if you are getting that level of legit comments that pushes you above Mollom Plus levels you are already running a cluster of boxes and the cost of custom solutions with them is going to be a drop in the bucket.
A little clarification, please:
You stated that that any port to 6 should be against HEAD. Are you referring to 5.x-3.0-beta1, 5.x-3.x-dev, or some other version that does not appear on the http://drupal.org/project/spam page?
I would like to help with the port, but I'm not sure where we need to start! For that matter, are any of the other patches listed on this page for the 3.x branch? Are they a good starting point?
I am motivated to help, because this one module may make or break several of my upcoming projects.
@corey: A 6.x branch should be derived from 5.x-3.x-dev. I do not believe any patches are against this version, so you'd be starting fresh. But your efforts would be greatly appreciated.
@corey: I am motivated to help test your updates, once we have a 6.x branch created.
Here's my first shot. Unfortunately, I don't know how to make a diff file that includes so many files, so I am uploading the entire folder/module set of files. (Yes, I'm on Vista...)
There is no upgrade path, since it is assumed that the user has already upgraded to v3, and there are no schema changes involved in upgrading from D5 to D6 (in the module, that is).
I know it's a lot of information to wade through, but I hope someone can help us with the testing. I would love for this to be able to become a 6.x-3.x-dev.
PS - It looks like an extra "_" was added to the file name. It should have been spam.tar.gz .
OK, I feel dumb... I found an incorrectly named function just after I uploaded the previous file. Try this one instead.
I'm on holiday, but will try to review shortly. Patches are greatly preferred to whole files, the latter being decidedly more difficult to review. It is fine to attach many files, no need to combine all your patches into one file. Also, that is correct about the upgrade path, the 6.x branch is for people upgrading from the 5.x3.x branch, from which there are currently no schema changes.
great work, thanks.
I've converted your tarball into a patch for easier review, attached.
Thanks for the patch, Corey! Committed. Happy holidays!
Testing 6.x-1.x-dev and subscribing to Thread
Automatically closed -- issue fixed for two weeks with no activity.
This issue has no child issues.
Drupal is a registered trademark of Dries Buytaert.