- Development - lists.drupal.org

[drupal-devel] [bug] new revisions not created if user doesn't have administer nodes permission
by mcd 14 Jan '05

14 Jan '05

Project: Drupal Version: 4.5.0 Component: node system Category: bug reports Priority: critical Assigned to: wazdog Reported by: wazdog Updated by: mcd Status: patch Rolling back nondestructively is just a means of editing a page. Why should a user with permission to edit be prevented from that edit? They can certainly do more destructive things. As for creating new revisions every time, it depends on usage patterns. You may not want too many almost indistinguishable revisions collecting in the revisions tab. mcd Previous comments: ------------------------------------------------------------------------ November 1, 2004 - 03:33 : wazdog If you enable revisions for a node type via content > configure > default workflow, and the user who is editing a node of that type doesn't have the administer nodes permission, then a new revision is not created. I see this a huge bug. I am trying to have all edits to a node type saved as revisions (in this case a flexinode, but I also tested with blog types). I want to recreate the book pages, but with more fields (hence, flexinode). But if one of my authenticated users creates a node, and then later edits it, a revision is not made. However, if an admin or moderator (who both have the administer nodes permission) edits the node, a new revision is created. I don't want my regular users to have administer nodes permission, that gives them too much power, but their revisions need to be kept (just like I give them all publish permission via default workflow). If this is supposed to be how it works, what is the point of the default workflow setting? (and why do the other default workflow settings behave differently? i.e. they all apply no matter the users permissions) ------------------------------------------------------------------------ November 2, 2004 - 19:48 : wazdog Attachment: http://drupal.org/files/issues/node-rev.patch (721 bytes) Okay, here's a short little patch. It seems like node_create_revision() was being called before $node->revision was set. Since $node->revision is what tells Drupal whether or not to make a new revision, this was causing nodes to not keep revisions. I moved node_create_revision() to after this check. I'm not sure exactly why only regular users without 'administer nodes' permission were affected, but that seems the case. Now, if a particular node type has 'revision' checked in content > default workflow, a new revision is always created, no matter who is doing the editing... I'm setting this to critical because I think the current behavior goes against logic, and what admins may expect. And if they don't notice it's not working like they expect (i.e. revisions aren't being kept always), then content is lost... The patch is against 4.5.0, but always applies to current cvs (with a slight offset error). ------------------------------------------------------------------------ January 14, 2005 - 15:54 : mcd I tried this patch against 4.5.1 and it worked, but it took me some time to figure out that it was working because it's still not doing the intuitive thing. The user still can't see the revisions tab unless they have node administration privileges (which makes it unlike the outline tab). They can't see the checkbox to decide whether their edit is a new revision, so every edit they do becomes a revision from which they derive no benefit. I would let them see the revision checkbox and the revisions tab, and also roll back (non-destructively as suggested in http://drupal.org/node/12479) I don't think there is an intuitive way to handle the five node administration Options checkboxes as a group while appearing to enable them separately in the default workflow. I've had similar issues with the defaults, like a page I made sticky coming unstuck every time the owner edited it (with the default non-sticky in the workflow). Now I see why that was happening, but it's still highly counterintuitive. ------------------------------------------------------------------------ January 14, 2005 - 15:56 : mcd Sorry, I didn't mean to change the main title. ------------------------------------------------------------------------ January 14, 2005 - 16:11 : chx IMHO in some situations it is a good thing if a new revision is created every time a user edits the node. It's not her privilege to roll back, it's something a moderator should do. It'd be even better if the new revision would not be automatically published only after approval by the moderator. -- View: http://drupal.org/node/12401 Edit: http://drupal.org/project/comments/add/12401

1 0

[drupal-devel] [bug] new revisions not created if user doesn't have administer nodes permission
by chx 14 Jan '05

14 Jan '05

Project: Drupal Version: 4.5.0 Component: node system Category: bug reports Priority: critical Assigned to: wazdog Reported by: wazdog Updated by: chx Status: patch IMHO in some situations it is a good thing if a new revision is created every time a user edits the node. It's not her privilege to roll back, it's something a moderator should do. It'd be even better if the new revision would not be automatically published only after approval by the moderator. chx Previous comments: ------------------------------------------------------------------------ November 1, 2004 - 09:33 : wazdog If you enable revisions for a node type via content > configure > default workflow, and the user who is editing a node of that type doesn't have the administer nodes permission, then a new revision is not created. I see this a huge bug. I am trying to have all edits to a node type saved as revisions (in this case a flexinode, but I also tested with blog types). I want to recreate the book pages, but with more fields (hence, flexinode). But if one of my authenticated users creates a node, and then later edits it, a revision is not made. However, if an admin or moderator (who both have the administer nodes permission) edits the node, a new revision is created. I don't want my regular users to have administer nodes permission, that gives them too much power, but their revisions need to be kept (just like I give them all publish permission via default workflow). If this is supposed to be how it works, what is the point of the default workflow setting? (and why do the other default workflow settings behave differently? i.e. they all apply no matter the users permissions) ------------------------------------------------------------------------ November 3, 2004 - 01:48 : wazdog Attachment: http://drupal.org/files/issues/node-rev.patch (721 bytes) Okay, here's a short little patch. It seems like node_create_revision() was being called before $node->revision was set. Since $node->revision is what tells Drupal whether or not to make a new revision, this was causing nodes to not keep revisions. I moved node_create_revision() to after this check. I'm not sure exactly why only regular users without 'administer nodes' permission were affected, but that seems the case. Now, if a particular node type has 'revision' checked in content > default workflow, a new revision is always created, no matter who is doing the editing... I'm setting this to critical because I think the current behavior goes against logic, and what admins may expect. And if they don't notice it's not working like they expect (i.e. revisions aren't being kept always), then content is lost... The patch is against 4.5.0, but always applies to current cvs (with a slight offset error). ------------------------------------------------------------------------ January 14, 2005 - 21:54 : mcd I tried this patch against 4.5.1 and it worked, but it took me some time to figure out that it was working because it's still not doing the intuitive thing. The user still can't see the revisions tab unless they have node administration privileges (which makes it unlike the outline tab). They can't see the checkbox to decide whether their edit is a new revision, so every edit they do becomes a revision from which they derive no benefit. I would let them see the revision checkbox and the revisions tab, and also roll back (non-destructively as suggested in http://drupal.org/node/12479) I don't think there is an intuitive way to handle the five node administration Options checkboxes as a group while appearing to enable them separately in the default workflow. I've had similar issues with the defaults, like a page I made sticky coming unstuck every time the owner edited it (with the default non-sticky in the workflow). Now I see why that was happening, but it's still highly counterintuitive. ------------------------------------------------------------------------ January 14, 2005 - 21:56 : mcd Sorry, I didn't mean to change the main title. -- View: http://drupal.org/node/12401 Edit: http://drupal.org/project/comments/add/12401

1 0

[drupal-devel] [bug] new revisions not created if user doesn't have administer nodes permission
by mcd 14 Jan '05

14 Jan '05

Project: Drupal Version: 4.5.0 Component: node system Category: bug reports Priority: critical Assigned to: wazdog Reported by: wazdog Updated by: mcd Status: patch Sorry, I didn't mean to change the main title. mcd Previous comments: ------------------------------------------------------------------------ November 1, 2004 - 03:33 : wazdog If you enable revisions for a node type via content > configure > default workflow, and the user who is editing a node of that type doesn't have the administer nodes permission, then a new revision is not created. I see this a huge bug. I am trying to have all edits to a node type saved as revisions (in this case a flexinode, but I also tested with blog types). I want to recreate the book pages, but with more fields (hence, flexinode). But if one of my authenticated users creates a node, and then later edits it, a revision is not made. However, if an admin or moderator (who both have the administer nodes permission) edits the node, a new revision is created. I don't want my regular users to have administer nodes permission, that gives them too much power, but their revisions need to be kept (just like I give them all publish permission via default workflow). If this is supposed to be how it works, what is the point of the default workflow setting? (and why do the other default workflow settings behave differently? i.e. they all apply no matter the users permissions) ------------------------------------------------------------------------ November 2, 2004 - 19:48 : wazdog Attachment: http://drupal.org/files/issues/node-rev.patch (721 bytes) Okay, here's a short little patch. It seems like node_create_revision() was being called before $node->revision was set. Since $node->revision is what tells Drupal whether or not to make a new revision, this was causing nodes to not keep revisions. I moved node_create_revision() to after this check. I'm not sure exactly why only regular users without 'administer nodes' permission were affected, but that seems the case. Now, if a particular node type has 'revision' checked in content > default workflow, a new revision is always created, no matter who is doing the editing... I'm setting this to critical because I think the current behavior goes against logic, and what admins may expect. And if they don't notice it's not working like they expect (i.e. revisions aren't being kept always), then content is lost... The patch is against 4.5.0, but always applies to current cvs (with a slight offset error). ------------------------------------------------------------------------ January 14, 2005 - 15:54 : mcd I tried this patch against 4.5.1 and it worked, but it took me some time to figure out that it was working because it's still not doing the intuitive thing. The user still can't see the revisions tab unless they have node administration privileges (which makes it unlike the outline tab). They can't see the checkbox to decide whether their edit is a new revision, so every edit they do becomes a revision from which they derive no benefit. I would let them see the revision checkbox and the revisions tab, and also roll back (non-destructively as suggested in http://drupal.org/node/12479) I don't think there is an intuitive way to handle the five node administration Options checkboxes as a group while appearing to enable them separately in the default workflow. I've had similar issues with the defaults, like a page I made sticky coming unstuck every time the owner edited it (with the default non-sticky in the workflow). Now I see why that was happening, but it's still highly counterintuitive. -- View: http://drupal.org/node/12401 Edit: http://drupal.org/project/comments/add/12401

1 0

[drupal-devel] [bug] non-intuitive revisions
by mcd 14 Jan '05

14 Jan '05

Project: Drupal Version: 4.5.0 Component: node system Category: bug reports Priority: critical Assigned to: wazdog Reported by: wazdog Updated by: mcd Status: patch I tried this patch against 4.5.1 and it worked, but it took me some time to figure out that it was working because it's still not doing the intuitive thing. The user still can't see the revisions tab unless they have node administration privileges (which makes it unlike the outline tab). They can't see the checkbox to decide whether their edit is a new revision, so every edit they do becomes a revision from which they derive no benefit. I would let them see the revision checkbox and the revisions tab, and also roll back (non-destructively as suggested in http://drupal.org/node/12479) I don't think there is an intuitive way to handle the five node administration Options checkboxes as a group while appearing to enable them separately in the default workflow. I've had similar issues with the defaults, like a page I made sticky coming unstuck every time the owner edited it (with the default non-sticky in the workflow). Now I see why that was happening, but it's still highly counterintuitive. mcd Previous comments: ------------------------------------------------------------------------ November 1, 2004 - 03:33 : wazdog If you enable revisions for a node type via content > configure > default workflow, and the user who is editing a node of that type doesn't have the administer nodes permission, then a new revision is not created. I see this a huge bug. I am trying to have all edits to a node type saved as revisions (in this case a flexinode, but I also tested with blog types). I want to recreate the book pages, but with more fields (hence, flexinode). But if one of my authenticated users creates a node, and then later edits it, a revision is not made. However, if an admin or moderator (who both have the administer nodes permission) edits the node, a new revision is created. I don't want my regular users to have administer nodes permission, that gives them too much power, but their revisions need to be kept (just like I give them all publish permission via default workflow). If this is supposed to be how it works, what is the point of the default workflow setting? (and why do the other default workflow settings behave differently? i.e. they all apply no matter the users permissions) ------------------------------------------------------------------------ November 2, 2004 - 19:48 : wazdog Attachment: http://drupal.org/files/issues/node-rev.patch (721 bytes) Okay, here's a short little patch. It seems like node_create_revision() was being called before $node->revision was set. Since $node->revision is what tells Drupal whether or not to make a new revision, this was causing nodes to not keep revisions. I moved node_create_revision() to after this check. I'm not sure exactly why only regular users without 'administer nodes' permission were affected, but that seems the case. Now, if a particular node type has 'revision' checked in content > default workflow, a new revision is always created, no matter who is doing the editing... I'm setting this to critical because I think the current behavior goes against logic, and what admins may expect. And if they don't notice it's not working like they expect (i.e. revisions aren't being kept always), then content is lost... The patch is against 4.5.0, but always applies to current cvs (with a slight offset error). -- View: http://drupal.org/node/12401 Edit: http://drupal.org/project/comments/add/12401

1 0

[drupal-devel] Should there be a revisions permission?
by Robert Douglass 14 Jan '05

14 Jan '05

Hi all, I was wondering what thoughts there are on why revisions require the 'administer nodes' permission and don't have their own? There are many things that 'administer nodes' allows you to do (access node admin pages, different node validation, access to the admin form elements in node creation etc.) which are significantly different in nature and scope than revisions of nodes. It seems to me that there are cases where normal users should be able to make revisions without having access to the other stuff. Thoughts? cheers, Robert -- visit me at www.robshouse.net!

2 1

[drupal-devel] Inter-module function calls
by Sheldon Rampton 14 Jan '05

14 Jan '05

Can someone tell me what the best way is for me to invoke functions from an existing module when writing a new module? For example, "taxonomy_get_vocabularies" from the taxonomy module works fine if I call it directly from within a new module I'm writing, but is it kosher to do this? Should I be using module_invoke instead? -- -------------------------------- | Sheldon Rampton | Research director, Center for Media & Democracy (www.prwatch.org) | Author of books including: | Friends In Deed: The Story of US-Nicaragua Sister Cities | Toxic Sludge Is Good For You | Mad Cow USA | Trust Us, We're Experts | Weapons of Mass Deception | Banana Republicans -------------------------------- | Subscribe to our free weekly list serve by visiting: | http://www.prwatch.org/cmd/subscribe_sotd.html | | Donate now to support independent, public interest reporting: | https://secure.groundspring.org/dn/index.php?id=1118 --------------------------------

2 1

[drupal-devel] re: that node design mock-ups
by Charlie Lowe 14 Jan '05

14 Jan '05

Ber wrote, ". . . . This all dictates we take this project structurally, start bottom up: What can nodeapi do, where can it do that, what can appear, what not etc. The only thing that is required, ATM is the title, all other elements might (and thus eventually will) appear or disappear." I agree. Note that if a modular approach is used, once implemented, it will allow theme designers the ability to begin experimenting with various UI layouts. So FactoryJoe's particular input design might be the default in Drupal core for the next release. Theme designers will of course tweak it, change it around given enough felxibility, and the UI will continue to evolve. In subsequent Drupal releases, the best practices can be implemented as the default layout for Drupal core. But none of the theme designers need feel locked into it; they can always work to improve it on their own. IMHO, this is a good emergent model for developing the UI which will also make Drupal more attractive to designers. BTW: I also posted another mockup to the discussion thread in reply to yours. Charlie

2 1

[drupal-devel] [task] This is a Title
by Anonymous 14 Jan '05

14 Jan '05

Project: User experience Version: <none> Component: accessability Category: tasks Priority: critical Assigned to: Anonymous Reported by: Anonymous Updated by: Anonymous Status: patch this it a description, this it a description, this it a description, this it a description, this it a description, this it a description, this it a description, this it a description, this it a description, this it a description, this it a description, this it a description, this it a description, this it a description, this it a description, this it a description, this it a description, this it a description, this it a description, this it a description, this it a description, this it a description, this it a description, this it a description, this it a description, this it a description, this it a description, this it a description, this it a description, this it a description, this it a description, this it a description, this it a description, this it a description, this it a description, this it a description, this it a description, this it a description, this it a description, this it a description, this it a description, this it a description, this it a description, this it a description, this it a description, this it a description, this it a description, this it a description, this it a description, this it a description, this it a description, this it a description, this it a description, this it a description, this it a description, this it a description, this it a description, this it a description, this it a description, this it a description, this it a description, this it a description, this it a description, this it a description, this it a description, this it a description, this it a description, this it a description, this it a description, this it a description, this it a description, this it a description, this it a description, this it a description, this it a description, this it a description, this it a description, this it a description, this it a description, Anonymous -- View: http://drupal.org/node/15606 Edit: http://drupal.org/project/comments/add/15606

1 0

[drupal-devel] [bug] Ignore unpublished comments when determining last_post
by killes 14 Jan '05

14 Jan '05

Project: Drupal Version: 4.5.0 Component: tracker.module Category: bug reports Priority: normal Assigned to: Morbus Iff Reported by: Morbus Iff Updated by: killes(a)www.drop.org Status: patch I think it makes sense to only select published comments. I think this bugfix should go in both 4.5 and cvs. +1 killes(a)www.drop.org Previous comments: ------------------------------------------------------------------------ January 12, 2005 - 17:02 : Morbus Iff The automated unpublishing is great for stopping spam from being displayed, but it doesn't stop spam from corrupting another feature: my "recent posts" (tracker.module). I'll regularly get bursts of 200 auto-unpublished spams which make the "recent posts" page useless - an unpublished spam still affects the modification date of a node, which makes "recent posts" display craploads of updates, even though there really isn't any. Thus, the feature request would be: - treat an unpublished spam as a deleted spam - when a spam is automatically unpublished, revert the node modification date to its previous value. I'm not entirely sure how easily possible this is, as you'd have to make sure the date is properly set when someone says "nah, this unpublished spam was actual ham", and then republishes it. ------------------------------------------------------------------------ January 12, 2005 - 20:41 : Jeremy(a)kerneltrap.org This is a known and annoying bug. As it affects me too, I assure you I'll get to fixing this eventually... Any ideas on how to cleanly implement this are welcome. ------------------------------------------------------------------------ January 13, 2005 - 22:27 : Morbus Iff Would it seem to you that this behavior should be part of core? Ignoring spam.module entirely, if a node is updated at 11:00, and then updated with a comment at 12:00, the 12:00 is saved in there as the node's modification time. But if a comment is unpublished, shouldn't the node also be reverted back to its previous state (being 11:00)? How is the deletion of data (permanently hiding it) different from merely temporarily hiding it (ie., unpublishing it)? Perhaps I should move request to Drupal. ------------------------------------------------------------------------ January 13, 2005 - 22:32 : Jeremy(a)kerneltrap.org Feel free to move it. If I come up with a clean solution (at least as far as spam is concerned), I'll update the issue wherever it is. ------------------------------------------------------------------------ January 13, 2005 - 22:39 : Morbus Iff Was talking about this with killes (who "frankly [doesn't] care too much about comments"), and I'm now wondering if I'm going nutty with all this talk about node and comment timestamps. We should investigate to see if tracker.module looks at /unpublished/ comment timestamps instead of just published ones. If it doesn't make a distinction, then it would theoretically be a quickie patch to a SQL statement to only check against published comment timestamps, not unpublished. ------------------------------------------------------------------------ January 13, 2005 - 22:42 : Morbus Iff With a quick look, it looks like tracker_page() only checks node.status, and not comment.status. We should be able to put a patch in for comment.status = 1 (unpublished being 2), and that should solve our problem, right? ------------------------------------------------------------------------ January 13, 2005 - 22:55 : Morbus Iff Apologies... "AND c.status = 0". Modifying the two queries in tracker_page() made things, seemingly, work as I desire. Can you confirm? ------------------------------------------------------------------------ January 13, 2005 - 23:02 : Jeremy(a)kerneltrap.org It didn't appear to help with regards to the spam module. I had a recent spam flood, and with or without the 'AND c.status = 0' I saw the same posts, including those with recently unpublished spam comments. ------------------------------------------------------------------------ January 13, 2005 - 23:08 : Morbus Iff Odd - I had one unpublished piece of spam that I tested against (for 4.5.0, not CVS), and modifying tracker.module seemed to work as I intended. So, the following bit of SQL still shows you erroneous nodes with unpublished comments? SELECT DISTINCT(n.nid), n.title, n.type, n.changed, n.uid, u.name, MAX(GREATEST(n.changed, c.timestamp)) AS last_post FROM node n LEFT JOIN comments c ON n.nid = c.nid INNER JOIN users u ON n.uid = u.uid WHERE n.status = 1 AND c.status = 0 AND '1' GROUP BY n.nid, n.title, n.type, n.changed, n.uid, u.name ORDER BY last_post DESC LIMIT 10; The above is what is actually run against my database with the proposed tracker.module change. (This code is currently active on gamegrene.com, so we can test live if need be. Submit a comment as an anonymous user with the words "poker" or "texas hold'em", and it should be a) unpublished automatically via your module, and b) not shown in the tracker. ------------------------------------------------------------------------ January 14, 2005 - 13:52 : Morbus Iff For what it's worth, I just woke up to another flood of 150 spams, and no corruption of my recent posts. ------------------------------------------------------------------------ January 14, 2005 - 14:05 : Jeremy(a)kerneltrap.org Then it sounds like a patch is in order... For the tracker module. ------------------------------------------------------------------------ January 14, 2005 - 14:59 : Morbus Iff Have you been able to confirm this though? ------------------------------------------------------------------------ January 14, 2005 - 15:46 : Morbus Iff Attachment: http://drupal.org/files/issues/tracker_0.patch (2.59 KB) Patch attached for 4.5.0. Haven't tried applying it to CVS, but it needs to go there too. -- View: http://drupal.org/node/15500 Edit: http://drupal.org/project/comments/add/15500

1 0

[drupal-devel] [bug] Ignore unpublished comments when determining last_post
by Morbus Iff 14 Jan '05

14 Jan '05

Project: Drupal Version: 4.5.0 Component: tracker.module Category: bug reports Priority: normal Assigned to: Morbus Iff Reported by: Morbus Iff Updated by: Morbus Iff Status: patch Attachment: http://drupal.org/files/issues/tracker_0.patch (2.59 KB) Patch attached for 4.5.0. Haven't tried applying it to CVS, but it needs to go there too. Morbus Iff Previous comments: ------------------------------------------------------------------------ January 12, 2005 - 11:02 : Morbus Iff The automated unpublishing is great for stopping spam from being displayed, but it doesn't stop spam from corrupting another feature: my "recent posts" (tracker.module). I'll regularly get bursts of 200 auto-unpublished spams which make the "recent posts" page useless - an unpublished spam still affects the modification date of a node, which makes "recent posts" display craploads of updates, even though there really isn't any. Thus, the feature request would be: - treat an unpublished spam as a deleted spam - when a spam is automatically unpublished, revert the node modification date to its previous value. I'm not entirely sure how easily possible this is, as you'd have to make sure the date is properly set when someone says "nah, this unpublished spam was actual ham", and then republishes it. ------------------------------------------------------------------------ January 12, 2005 - 14:41 : Jeremy(a)kerneltrap.org This is a known and annoying bug. As it affects me too, I assure you I'll get to fixing this eventually... Any ideas on how to cleanly implement this are welcome. ------------------------------------------------------------------------ January 13, 2005 - 16:27 : Morbus Iff Would it seem to you that this behavior should be part of core? Ignoring spam.module entirely, if a node is updated at 11:00, and then updated with a comment at 12:00, the 12:00 is saved in there as the node's modification time. But if a comment is unpublished, shouldn't the node also be reverted back to its previous state (being 11:00)? How is the deletion of data (permanently hiding it) different from merely temporarily hiding it (ie., unpublishing it)? Perhaps I should move request to Drupal. ------------------------------------------------------------------------ January 13, 2005 - 16:32 : Jeremy(a)kerneltrap.org Feel free to move it. If I come up with a clean solution (at least as far as spam is concerned), I'll update the issue wherever it is. ------------------------------------------------------------------------ January 13, 2005 - 16:39 : Morbus Iff Was talking about this with killes (who "frankly [doesn't] care too much about comments"), and I'm now wondering if I'm going nutty with all this talk about node and comment timestamps. We should investigate to see if tracker.module looks at /unpublished/ comment timestamps instead of just published ones. If it doesn't make a distinction, then it would theoretically be a quickie patch to a SQL statement to only check against published comment timestamps, not unpublished. ------------------------------------------------------------------------ January 13, 2005 - 16:42 : Morbus Iff With a quick look, it looks like tracker_page() only checks node.status, and not comment.status. We should be able to put a patch in for comment.status = 1 (unpublished being 2), and that should solve our problem, right? ------------------------------------------------------------------------ January 13, 2005 - 16:55 : Morbus Iff Apologies... "AND c.status = 0". Modifying the two queries in tracker_page() made things, seemingly, work as I desire. Can you confirm? ------------------------------------------------------------------------ January 13, 2005 - 17:02 : Jeremy(a)kerneltrap.org It didn't appear to help with regards to the spam module. I had a recent spam flood, and with or without the 'AND c.status = 0' I saw the same posts, including those with recently unpublished spam comments. ------------------------------------------------------------------------ January 13, 2005 - 17:08 : Morbus Iff Odd - I had one unpublished piece of spam that I tested against (for 4.5.0, not CVS), and modifying tracker.module seemed to work as I intended. So, the following bit of SQL still shows you erroneous nodes with unpublished comments? SELECT DISTINCT(n.nid), n.title, n.type, n.changed, n.uid, u.name, MAX(GREATEST(n.changed, c.timestamp)) AS last_post FROM node n LEFT JOIN comments c ON n.nid = c.nid INNER JOIN users u ON n.uid = u.uid WHERE n.status = 1 AND c.status = 0 AND '1' GROUP BY n.nid, n.title, n.type, n.changed, n.uid, u.name ORDER BY last_post DESC LIMIT 10; The above is what is actually run against my database with the proposed tracker.module change. (This code is currently active on gamegrene.com, so we can test live if need be. Submit a comment as an anonymous user with the words "poker" or "texas hold'em", and it should be a) unpublished automatically via your module, and b) not shown in the tracker. ------------------------------------------------------------------------ January 14, 2005 - 07:52 : Morbus Iff For what it's worth, I just woke up to another flood of 150 spams, and no corruption of my recent posts. ------------------------------------------------------------------------ January 14, 2005 - 08:05 : Jeremy(a)kerneltrap.org Then it sounds like a patch is in order... For the tracker module. ------------------------------------------------------------------------ January 14, 2005 - 08:59 : Morbus Iff Have you been able to confirm this though? -- View: http://drupal.org/node/15500 Edit: http://drupal.org/project/comments/add/15500

1 0