Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Into my site I enable spam and custom filter modules. When user create a node or submit a node into table {sessions}.session field there are serialized spam_form array. I check the problem and it's on modules/spam_node.inc file.
I remove it and problem desappair (i don't check node for spam, only comments). I think problem is into hook_nodeapi (this function don't check if node must be checked or not).
Comment | File | Size | Author |
---|---|---|---|
#3 | spam-712624.patch | 875 bytes | mavimo |
Comments
Comment #1
gnassar CreditAttribution: gnassar commentedI'm not sure I understand the problem. Could you please give more detail as to what specifically you're seeing and what goes wrong?
Comment #2
mavimo CreditAttribution: mavimo commentedHi gnassar, sorry for delay.
I have a drupal installation with this config:
When user with role1 create (or update) a Cont1 node, all information about this node is saved into {sessions} table. This node is very complex and into sessions i find approx 2Mb of data (really slow to read, write, ....). I analized spam module code and from first analysis the problem is into spam_node.inc. It call node_spam_scan function where put some data into
$_SESSION['spam_form']
, after that run spam_scan function. This function (if user have perm "bypass filters") run spam_log and return. After that function call there is notunsert($_SESSION['spam_form']);
and all data will be store into {sessions} table.
Comment #3
mavimo CreditAttribution: mavimo commentedPatch attached
Comment #4
mdorrell CreditAttribution: mdorrell commentedThis patch seems to be working for me. Can we get this placed in the next version?
Comment #5
Jeremy CreditAttribution: Jeremy commentedNice catch, thanks! This affects all content types, not just nodes, so I've expanded the patch, added comments, and committed it:
http://drupal.org/cvs?commit=468982
Comment #6
gnassar CreditAttribution: gnassar commentedWe actually throw a *lot* of session data around. The serialized form is probably the easiest to notice, because it's enormous. But we can probably get rid of quite a bit of this stuff.
Reclassifying as a normal "task," since the impact (after the patch -- nice work, mavimo and Jeremy) is not severe and does not cause execution errors.
Comment #7
AlexisWilke CreditAttribution: AlexisWilke commentedgnassar,
Is there any cases where that session data is needed as a session? Couldn't that be saved in a global variable, simply? (global $_spam_spam_form;) Because session data is saved in the database, whether or not it gets deleted right after... and if it gets deleted right after, why keep it in the DB in the first place? It's dead slow...
Actually, it seems to me that if it is necessary as a session in a few cases, then those cases can save that data in the session as required and thus we'd not have that saved every single time as it is now!
Thank you.
Alexis
Comment #8
apadernoI am closing this issue, since it's for a Drupal version no longer supported.