- Development - lists.drupal.org

[drupal-devel] [bug] Failure to respect node status upon editing (reverts to default)
by moshe weitzman 24 Jan '05

24 Jan '05

Project: Drupal Version: cvs Component: node system Category: bug reports Priority: normal Assigned to: mathias Reported by: mathias Updated by: moshe weitzman Status: patch this patch fixes a fairly undesirable problem with our workflow. lets consider it along with other proposed changes to default workflow. moshe weitzman Previous comments: ------------------------------------------------------------------------ May 20, 2004 - 22:00 : mathias How to recreate: 1. As admin, navigate to: administer » content » settings, and uncheck 'publish' for stories. 2. As admin, create a story and assign it to a user that can create and maintain their own stories, say this user's name is Mark. 3. Login as Mark and edit that story. 4. Instead of staying published, it reverts back to it's unpublished state. I think this behavior is a bug as these content settings are default settings and should only be applied during node creation (not editing). I know Drupal-contrib project owners get bitten with this everytime they edit their project pages. I'll work on a patch within the next day. ------------------------------------------------------------------------ May 21, 2004 - 10:59 : mathias Attachment: http://drupal.org/files/issues/node_defaults.patch (1.05 KB) Proposed solution: If a node is being updated: respect the following existing settings: 1. node status (published/unpublished) 2. node promotion (promoted on front page) 3. node static (static on front page) For any node, force the defaults for: 1. moderation 2. revisions With our current situation, say the admin makes 'promote to front page' and 'static on front page' the default settings for stories. Another user posts a story and bam! it's of course immediately visible. The admin decides he/she doesn't like that story and demotes it. Well as soon as that user edits his story, the default settings are re-assigned and his post is right back on the front page. ------------------------------------------------------------------------ August 3, 2004 - 14:38 : mathias Attachment: http://drupal.org/files/issues/node_defaults_0.patch (1.19 KB) When editing nodes, the following node properties should not be overwritten - node status (published/unpublished) - node promotion (promoted on front page) - node sticky (top of the list) Currently, if the author of a node doesn't have 'administer node' privileges, than the above settings will always revert to the default behavior of their node type group. This makes nodes disappear and node authors very very confused. ------------------------------------------------------------------------ August 3, 2004 - 14:56 : ccourtne Don't forget to take moderation into account. If a node is edited should it go back through moderation? Some sites may want the behavior of going back some sites may not. This is probably best as a toggle option on workflow default config screen. ------------------------------------------------------------------------ August 3, 2004 - 16:21 : mathias I don't think my patch interferes with the moderation features. If the default workflow for a type of nodes is set to 'moderate', than the moderation flag will always reset itself to 'moderation' upon editing. I did not alter this functionality. ------------------------------------------------------------------------ September 29, 2004 - 17:00 : mathias Attachment: http://drupal.org/files/issues/node_defaults_1.patch (1.64 KB) I was recently bitten by this bug again, so I'll try to describe the exact nature of the problem. If an user of a node doesn't have 'administer nodes' permission, than whenever they edit their own node the status, promotion, static, moderation and revision settings revert to their default state. This can cause: - A demoted post to once again be promoted. - A promoted post to be demoted. - A static post to disappear from the front page. All of these scenarios have happened to me simply by authors editing their own content. This patch allows all options except moderation and revision to stay with a node once it's created. Note: along a very similar line, the one-line 'node_validate does not respect group editing patch [1]' has been rolled into this as well. I'll take it out if need be. [1] http://drupal.org/node/11071 ------------------------------------------------------------------------ September 29, 2004 - 17:00 : mathias I was recently bitten by this bug again, so I'll try to describe the exact nature of the problem. If an user of a node doesn't have 'administer nodes' permission, than whenever they edit their own node the status, promotion, static, moderation and revision settings revert to their default state. This can cause: - A demoted post to once again be promoted. - A promoted post to be demoted. - A static post to disappear from the front page. All of these scenarios have happened to me simply by authors editing their own content. This patch allows all options except moderation and revision to stay with a node once it's created. Note: along a very similar line, the one-line 'node_validate does not respect group editing patch [2]' has been rolled into this as well. I'll take it out if need be. [2] http://drupal.org/node/11071 ------------------------------------------------------------------------ September 30, 2004 - 14:08 : Dries When someone edits a node that has been promoted, I do want to demote it from the main page. If not, the system is open for abuse. IMO, this is 'by design'. ------------------------------------------------------------------------ September 30, 2004 - 15:00 : Bèr Kessels Both Dries and Mathias have valid points here. If I add a post with loads of ugly stuff inside it, but an adminstrator decides not to delete it (because the post is still not too bad, or because of policy), but demote it, I can promote my spam next minute again by simply editing my content. This is bad. If I add a post with lots of good information, so that an administratr promotes it, next thing i can do is open it up and add loads of ugly spam to it. Buth are unwanted scenarios. The first is what we have now. The second is when this patch is committed. I think we need to seriously rething the workflow logic, maybe splitting workflow up into "add" and "edit". But maybe there are even better options? ------------------------------------------------------------------------ September 30, 2004 - 15:01 : Bèr Kessels Both Dries and Mathias have valid points here. If I add a post with loads of ugly stuff inside it, but an adminstrator decides not to delete it (because the post is still not too bad, or because of policy), but demote it, I can promote my spam next minute again by simply editing my content. This is bad. If I add a post with lots of good information, so that an administrator promotes it, next thing i can do is open it up and add loads of ugly spam to it. and then i have a promoted post with spam on that site. Both are unwanted scenarios. The first is what we have now. The second is when this patch is committed. I think we need to seriously rething the workflow logic, maybe splitting workflow up into "add" and "edit". But maybe there are even better options? ------------------------------------------------------------------------ September 30, 2004 - 15:02 : Bèr Kessels Both Dries and Mathias have valid points here. If I add a post with loads of ugly stuff inside it, but an adminstrator decides not to delete it (because the post is still not too bad, or because of policy), but demote it, I can promote my spam next minute again by simply editing my content. This is bad. If I add a post with lots of good information, so that an administrator promotes it, next thing i can do is open it up and add loads of ugly spam to it. and then i have a promoted post with spam on that site. Both are unwanted scenarios. The first is what we have now. The second is when this patch is committed. I think we need to seriously rething the workflow logic, maybe splitting workflow up into "add" and "edit". But maybe there are even better options? ------------------------------------------------------------------------ September 30, 2004 - 15:11 : Dries The first problem can be solved by blocking the user account, or by revoking the user's permissions. The second problem can probably be solved using the node-level permissions. Whenever I promote a post to the front page, I could revoke the user's edit rights. It would only work, if the modules don't by-pass the access rights, of course (I believe some do). ------------------------------------------------------------------------ October 3, 2004 - 16:28 : mathias Attachment: http://drupal.org/files/issues/node_defaults_2.patch (4.22 KB) Dries is right about using the power of node-level permissions for community editing. I think this patch would assist that goal. As it stands, node-level permissions don't work with community editing, at least in the sense we're used to. For one node_validate transfers ownership of the node to the current editing user which may not always be the author. This causes many problems since original authorship usually implies special privileges (e.g. 'edit own foo', delete). Second, sites have different trust levels for users. On some sites there's just a handful of trusted users that edit and maintain all the content. The current approach for community editing is to create a new role and give it the 'administer nodes' permission, which in my opinion makes the node form interface much more cluttered and gives users in that role full access to node properties. Full access is not always desired. Using a combination of node-level permissions and allowing a node to retain some or all of its options makes a clean, easy to use approach to maintainance. This new patch lets the admin control how node_validate handles node options during editing. It splits the default workflow screen into two parts: Creation settings, and Editing options. The creation settings is the default workflow we're all used to. The editing options allow the admin to say what happens to those node options when they are edited. I've created a node-level permissions module [3] based on JonBob's work that allows a user to choose which roles can view and/or edit their post. Unfortunately it needs this patch to allow node_validate to be a little less controlling. I'd like to contribute this module if it didn't need a patch. [3] http://www.asitis.org/tmp/ ------------------------------------------------------------------------ October 3, 2004 - 16:30 : mathias Attachment: http://drupal.org/files/issues/node_defaults_admin_content.png (22.39 KB) Screenshot of the new default 'node editing options' interface. ------------------------------------------------------------------------ October 4, 2004 - 10:16 : Bèr Kessels Mathias, First: using radio's for a Boolean is bad UI design IMO. It would be much better if you use checkboxes. Second: If you use radio's you can make the same matrix as above, for each node-type a reset foo flag. This will not only make the UI more consistent, but also improve usability by allowing per-node-type reset flag. Ber ------------------------------------------------------------------------ October 4, 2004 - 13:08 : Dries The settings GUI's help text is rather hard-core and will scare many user away. It will even frighten most Drupal developers. Also, I'm not sure I understood the screenshot correctly. The functionality introduced is much needed but the GUI and configuration parts needs work IMO. Keep working on it. ------------------------------------------------------------------------ October 14, 2004 - 16:55 : mathias Attachment: http://drupal.org/files/issues/node_defaults_3.patch (4.74 KB) As per Ber's feedback, I changed the interface to use checkboxes and allowed the reset flags to be set for each node-type. The result is a much more familiar and consistent experience. Dries: I revamped the help text, removing the scary bits and sticking to the bare essentials. The dialog concerning this patch has been excellent, and the result of which I feel is a sweet slice of code ready for core :) ------------------------------------------------------------------------ October 14, 2004 - 16:56 : mathias Attachment: http://drupal.org/files/issues/node_defaults_admin_content_0.png (18.68 KB) Latest screenshot of patch. ------------------------------------------------------------------------ October 28, 2004 - 15:08 : mathias Attachment: http://drupal.org/files/issues/node_defaults_4.patch (4.81 KB) Updated the help text to be slightly more descriptive, informing the reader that: Users with "administer nodes" permission can override the editing options. ------------------------------------------------------------------------ October 28, 2004 - 18:51 : Steven I'm not sure I like that admin interface. My brain tries to correlate the two tables, but the meanings are different (what is the value, keep the value?). Maybe it would be better just to have one checkbox per node type to allow you to either revert the published/frontpage/moderate/sticky fields on editing, or not. This should cover 99% of all use cases with an admin interface that is much easier to understand. ------------------------------------------------------------------------ October 30, 2004 - 14:29 : mathias Attachment: http://drupal.org/files/issues/node_defaults_5.patch (5.06 KB) It provides a consistant look and feel if the creation settings are the same as the editing settings since they both manipulate the same components of a node and you're just toggling states based on different actions. I think it is a bad idea to only give site admins an 'all or none' approach to override node options upon editing. Here are some examples why: - You want nodes to remember their 'sticky' setting, but unpublish themselves after editing. Once the node is approved, it goes right back to where it was. - You want nodes to remember their 'promote to front page' setting, but unpublish themselves after editing. Once the node is approved, it goes right back to where it was. - You want nodes to remember all their settings except moderation. The node is still published, but it goes into the queue to be rated again since the content has changed. - By default nodes are unpublished. Once it's been tagged as published it stays that way. Perhaps the moderation tag is reset. I've updated the code to hopefully make things even more clearer. Here's the latest screenshot [4]. [4] http://asitis.org/tmp/node_defaults_admin_content_1.png -- View: http://drupal.org/node/7940 Edit: http://drupal.org/project/comments/add/7940

1 0

[drupal-devel] [feature] Testers needed: Node Type filtering in taxonomy on Drupal 4.5
by jvandyk 24 Jan '05

24 Jan '05

Project: Drupal Version: cvs Component: taxonomy.module Category: feature requests Priority: normal Assigned to: matteo Reported by: matteo Updated by: jvandyk Status: patch Synonyms are useful for things like organisms, which have both a common name and a scientific name. That's the idea of synonyms, not necessarily the Drupal implementation of synonyms, which we plan to use but are not yet using. jvandyk Previous comments: ------------------------------------------------------------------------ October 25, 2004 - 21:20 : matteo Attachment: http://drupal.org/files/issues/taxonomy_nodetype_filter.patch (5.46 KB) The attached fix wants to add a new feature to taxonomy.module: the ability to filter data also on node types. This is a need when you have to share one vocabulary between multiple node types. One example is the vocabulary 'Geography', containing all Cities and Regions. You could have events, stories and other custom made node types, sharing this vocabulary. The need arises when you want to see only events of a certain region; if you filter only on region, you'll see also stories and the other custom node types. The new syntax is the following: taxonomy/term/term1,term2,term3(nodetype1,nodetype2)/........ to filter based on three terms (in OR each others) and on two different node types or taxonomy/term/term1+term2+term3(nodetype1,nodetype2)/........ to filter based on three terms (in AND each others) and on two different node types The rest of the syntax for taxonomy/term remains the same, and the patch works also for taxonomy feed. Node types are tested for validity. You can specify one or more node types; if you omit node types, normal term filtering is issued. Feedbacks and help testing this patch is needed; personally, I think this would improve temendously taxonomy functionalities, and hope this will be committed to Drupal core. Feel free to contact me by mail: m dot ferrari at tiscali dot it Matteo ------------------------------------------------------------------------ October 25, 2004 - 21:25 : moshe weitzman see http://drupal.org/node/5040 ------------------------------------------------------------------------ October 25, 2004 - 21:46 : matteo I agree with you that this is an old story, but nothing has been committed to 4.5, that introduced also a new taxonomy syntax. My patch has also some pluses: - it is specific for 4.5 and takes care of the new taxonomy syntax - it lets you specify multiple node types - syntax is clean Matteo ------------------------------------------------------------------------ January 19, 2005 - 22:05 : robclay Will this work with 4.5.2? If so - I am looking for exactly this funcionality! ------------------------------------------------------------------------ January 20, 2005 - 05:43 : matteo I'll work on a port for 4.5.2 hopefully next week... I'll keep you informed. Matteo ------------------------------------------------------------------------ January 23, 2005 - 23:19 : matteo Attachment: http://drupal.org/files/issues/taxonomy_nodetype_452.patch (4.43 KB) Here is the patch that adds nodetype filtering capabilities to 4.5.2 taxonomy module. Syntax is backwards compatible, so if you plan not to use node type filtering, syntax does not change at all. (see previous postings in this thread) I would need extensive testing and feedback... and hope this functionality will be included into Drupal core. Matteo ------------------------------------------------------------------------ January 23, 2005 - 23:38 : Steven New features only get added to the HEAD branch... you'll have to update your patch. ------------------------------------------------------------------------ January 24, 2005 - 06:56 : matteo Ok, Steven, I'll rewrite the patch also for CVS.... Thanks Matteo ------------------------------------------------------------------------ January 24, 2005 - 09:16 : matteo Attachment: http://drupal.org/files/issues/taxonomy_nodetype_CVS.patch (4.05 KB) Here is the patch for Drupal CVS. I noticed the great addition of node_rewrite_sql... very powerful... I'm starting extensive testing on the patch, and I really woul like it to be added to core taxonomy, because it becomes a must for several sites... Matteo ------------------------------------------------------------------------ January 24, 2005 - 14:43 : moshe weitzman I'd rather see this done universally (not just for taxonomy urls) using the new sql rewrite capability. specifically, some code will implement the rewrite_sql hook and look for a querystring param &ntype=blog,story and then inject the proper WHERE clause. this will be very useful for tracker, home page, taxonomy urls, etc. ------------------------------------------------------------------------ January 24, 2005 - 15:59 : Dries Before looking at the code (which violates Drupal's coding style), what do people think about the proposed URL scheme? Can anyone tell me why we use 'taxonomy/term/$foo' and not just 'taxonomy/$foo'? How about we change that to: taxonomy/all/$foo (or taxonomy/$foo) taxonomy/forum/$foo taxonomy/forum,book/$foo ... instead of the proposed URL scheme? It looks slightly more readable to me. (Does anyone know what 'synonyms' are for, and whether they could solve this problem? Really, I have no idea what these are for, even after having read the documentation.) -- View: http://drupal.org/node/12114 Edit: http://drupal.org/project/comments/add/12114

1 0

[drupal-devel] [feature] Create extra form elements for comment form
by Dries 24 Jan '05

24 Jan '05

Project: Drupal Version: cvs Component: comment.module Category: feature requests Priority: normal Assigned to: nysus Reported by: nysus Updated by: Dries Status: patch I'd vote against a contentapi at this point: I don't think it adds real value. I'm OK with a comment API and a node API (which IMO should be called _node() not _nodeapi()). Dries Previous comments: ------------------------------------------------------------------------ November 26, 2004 - 22:33 : nysus Like node forms which allow modules to use the nodeapi hook to prepend and append form elements to the node form, this simple change lets modules do the same for the comment form. Like node form, it also relies on the nodeapi hook. I plan to use it for an improvement to the subscriptions module that I have written which allows users to subscribe to individual comments without having to subscribe to an entire node. This change to the core was recommended by Moshe Weitzam found here: http://lists.drupal.org/archives/drupal-devel/2004-11/msg00256.html Thanks for the tip, Moshe! ------------------------------------------------------------------------ November 26, 2004 - 22:34 : nysus Attachment: http://drupal.org/files/issues/comment_8.patch (278 bytes) Oops, would help to attach the patch, eh? ------------------------------------------------------------------------ November 26, 2004 - 23:04 : TDobes A few things: 1. Please use the unified diff format for making patches -- see http://drupal.org/patch 2. I believe the suggestion was to add these features to hook_comment [1], not hook_nodeapi. nodeapi is just for nodes... comment is just for comments. 3. (not really related to yoru patch) Wouldn't it make more sense to have a hook_commentapi rather than a hook_comment? It seems like this would be more consistent with the naming of hook_nodeapi. 4. Many of the nodeapi $op values [2] could also apply to comments. Adding these to a commentapi could really open a lot of nice possibilities for modules. [1] http://drupaldocs.org/api/head/function/hook_comment [2] http://drupaldocs.org/api/head/function/hook_nodeapi ------------------------------------------------------------------------ November 26, 2004 - 23:36 : nysus TDobes, I don't know if you read the thread from the previous discussion, but there I pointed out that I didn't think the hook_comment seemed like the right function to modify. As far as creating a commentapi function, I thought about that. But I wondered if adding all the code necessary to support it was really worth it. You can use the pre-existing nodeapi to accomplish the same exact thing. And you won't have to create a new commentapi function in the comment.module and you won't have to create a new function in each of the modules that wants to use it. All you have to do is slap another case in the module's _nodeapi hook. So, you've got this in the comment.module's theme_comment_form() function: // Append extra comment form elements $form .= implode('', node_invoke_nodeapi($edit, 'comment form post')); And then in the subscription.module, you've got the following in the subscription_nodeapi() function: I understand your concern about maintaining naming conventions. Perhaps the nodeapi hook should be given a new name since it can have functionality beyond nodes. PS: Yeah, I know about patching with -u switch, just forgot. ------------------------------------------------------------------------ November 27, 2004 - 00:01 : TDobes I did read the thread that you linked to. At the moment (before your patch), hook_nodeapi is ONLY concerned with nodes. I believe it should stay that way. It is not that much more work for module authors to add a _comment (or _commentapi if we rename it) function to their module. On the other hand, it would be exceptionally confusing for people new to Drupal if we placed comment functions in a node hook. If we do decide to combine both hooks, I agree with you that nodeapi should be renamed. However, for the time being, I do not feel this is necessary. So... I agree with you that this would be a nice feature. However, I'd prefer a larger, more logical patch (adding to hook_comment) to a small and confusing patch (sticking this in hook_nodeapi, where it doesn't belong, IMO). But that's just my opinion... we'll have to see what others think. ------------------------------------------------------------------------ November 27, 2004 - 00:03 : nysus TDobes, OK, after rereading what you wrote and thinking about this some more, I think I may see a small advantage to having a separate hook_comment function. You are saying you could use the same op code string for both the hook_comment and nodeapi, right? But how about if the op code string were appended in some standardized way so the module _nodeapi hook could still be used? For example, you could prepend 'comment' to each of the codes for each operation that dealt with comments. So you'd have 'add' for when a node is added use 'comment add' for when a comment is added. 'insert' would be used for nodes and 'comment insert' for when comments are inserted. I guess it all boils down to the larger question I raised earler: Do we really need a separate _comment hook? ------------------------------------------------------------------------ November 27, 2004 - 00:06 : nysus Right, let's see what others think and go from there. Anyone? ------------------------------------------------------------------------ November 27, 2004 - 00:19 : Steven Hook_comment /is/ comment API. Renaming it to hook_commentapi seems like a good consistency idea. Putting all this inside hook_nodeapi is unacceptable and unclean. ------------------------------------------------------------------------ November 27, 2004 - 01:10 : moshe weitzman the best idea proposed by jhriggs was to combine nodeapi, commentapi, and user hooks into one contentapi hook. see http://lists.drupal.org/archives/drupal-devel/2004-07/msg00614.html in that msg, jhriggs prefers a single contentapi() hook over multiple $op specific hooks. Thats my slight preference as well. ------------------------------------------------------------------------ November 27, 2004 - 01:23 : Steven The contentapi puts us back in the discussion of "what is content?". Are users content? What about user profiles? etc. I don't think a generalized contentapi hook will help us though. A module will rarely affect nodes, comments and users at the same time. Almost all modules will implement contentapi and have a if ($type == 'node') or if ($type == 'comment') at the beginning. This makes the code more complicated than it should. It is also bad from a performance point of view to call every module which does something with nodes, comments or users when an operation is performed on any of them. ------------------------------------------------------------------------ November 27, 2004 - 05:51 : nysus After a little more consideration and after reading some of the comments here, I'll just recode this so that it uses the hook_comment. It just doesn't make sense to try to push through a fundamental change to Drupal's API to accomodate this small patch. ------------------------------------------------------------------------ November 27, 2004 - 06:37 : nysus Attachment: http://drupal.org/files/issues/comment_9.patch (876 bytes) OK, here's a second revision that works with hook_comment() instead. ------------------------------------------------------------------------ November 27, 2004 - 10:45 : Dries "Wouldn't it make more sense to have a hook_commentapi rather than a hook_comment? It seems like this would be more consistent with the naming of hook_nodeapi." No, but it would make sense to rename hook_nodeapi to hook_node. ------------------------------------------------------------------------ November 29, 2004 - 19:01 : jhriggs I still like the _contentapi() idea. I have discussed it several times with Kjartan, and although we have a few differences in opinion as to exactly how it should be coded, we both agree that it would be useful functionality. It does raise the "What is content?" question as Steven points out. Perhaps another name would be more appropriate. I do see tremendous benefit in having a single entry-point for this type of extensibility, though. Say for example that I want to append some type of disclaimer or a verification step (a la captcha or a similar module I wrote awhile back) in every submission form, be it node, comment, poll vote, user registration, profile, etc. I would only have to handle it in one place. Every time I receive a 'form pre' or 'form post', I can insert my content...or I can handle certain cases differently if desired (based on the type of content). Additionally, any module would be able to benefit from the logic. Instead of having somewhat overlapping _nodeapi(), _user(), and _comment() functionality like we do now (or will have even more of with the patch proposed here), we would have one invocation function that any module can use for any type of content that they define (i.e. user in user module, profile in profile.module, node in node.module, comment in comment.module, poll vote form in poll.module, etc.). Finally, as I have also discussed with Kjartan, functionality like this would mean that project.module would not have to use its own comment system (lots of duplicated code). It would be able to use the enhanced form-insertion and verification available through the hook. If there is sufficient interest, I will revive/rework the patch that I have started several times... ------------------------------------------------------------------------ December 24, 2004 - 08:48 : TDobes There's a similar discussion going on in another issue [3]... one of these should be marked as a duplicate. [3] http://drupal.org/node/14708 ------------------------------------------------------------------------ January 22, 2005 - 11:44 : stefan nagtegaal @ TDobes: The other issue is marked as 'duplicate', while here is the most interesting discussion going on about contentapi() vs. nodeapi()/commentapi().. Dries, what is you opinion about this? What needs to be done to get a patch like this in core? - Should we code the proposed contentapi()? - Another implementation? I really would like this in before we freeze HEAD, so i'm willing to cooperate in this.. -- View: http://drupal.org/node/13539 Edit: http://drupal.org/project/comments/add/13539

1 0

[drupal-devel] [feature] Testers needed: Node Type filtering in taxonomy on Drupal 4.5
by Dries 24 Jan '05

24 Jan '05

Project: Drupal Version: cvs Component: taxonomy.module Category: feature requests Priority: normal Assigned to: matteo Reported by: matteo Updated by: Dries Status: patch Before looking at the code (which violates Drupal's coding style), what do people think about the proposed URL scheme? Can anyone tell me why we use 'taxonomy/term/$foo' and not just 'taxonomy/$foo'? How about we change that to: taxonomy/all/$foo (or taxonomy/$foo) taxonomy/forum/$foo taxonomy/forum,book/$foo ... instead of the proposed URL scheme? It looks slightly more readable to me. (Does anyone know what 'synonyms' are for, and whether they could solve this problem? Really, I have no idea what these are for, even after having read the documentation.) Dries Previous comments: ------------------------------------------------------------------------ October 25, 2004 - 23:20 : matteo Attachment: http://drupal.org/files/issues/taxonomy_nodetype_filter.patch (5.46 KB) The attached fix wants to add a new feature to taxonomy.module: the ability to filter data also on node types. This is a need when you have to share one vocabulary between multiple node types. One example is the vocabulary 'Geography', containing all Cities and Regions. You could have events, stories and other custom made node types, sharing this vocabulary. The need arises when you want to see only events of a certain region; if you filter only on region, you'll see also stories and the other custom node types. The new syntax is the following: taxonomy/term/term1,term2,term3(nodetype1,nodetype2)/........ to filter based on three terms (in OR each others) and on two different node types or taxonomy/term/term1+term2+term3(nodetype1,nodetype2)/........ to filter based on three terms (in AND each others) and on two different node types The rest of the syntax for taxonomy/term remains the same, and the patch works also for taxonomy feed. Node types are tested for validity. You can specify one or more node types; if you omit node types, normal term filtering is issued. Feedbacks and help testing this patch is needed; personally, I think this would improve temendously taxonomy functionalities, and hope this will be committed to Drupal core. Feel free to contact me by mail: m dot ferrari at tiscali dot it Matteo ------------------------------------------------------------------------ October 25, 2004 - 23:25 : moshe weitzman see http://drupal.org/node/5040 ------------------------------------------------------------------------ October 25, 2004 - 23:46 : matteo I agree with you that this is an old story, but nothing has been committed to 4.5, that introduced also a new taxonomy syntax. My patch has also some pluses: - it is specific for 4.5 and takes care of the new taxonomy syntax - it lets you specify multiple node types - syntax is clean Matteo ------------------------------------------------------------------------ January 20, 2005 - 00:05 : robclay Will this work with 4.5.2? If so - I am looking for exactly this funcionality! ------------------------------------------------------------------------ January 20, 2005 - 07:43 : matteo I'll work on a port for 4.5.2 hopefully next week... I'll keep you informed. Matteo ------------------------------------------------------------------------ January 24, 2005 - 01:19 : matteo Attachment: http://drupal.org/files/issues/taxonomy_nodetype_452.patch (4.43 KB) Here is the patch that adds nodetype filtering capabilities to 4.5.2 taxonomy module. Syntax is backwards compatible, so if you plan not to use node type filtering, syntax does not change at all. (see previous postings in this thread) I would need extensive testing and feedback... and hope this functionality will be included into Drupal core. Matteo ------------------------------------------------------------------------ January 24, 2005 - 01:38 : Steven New features only get added to the HEAD branch... you'll have to update your patch. ------------------------------------------------------------------------ January 24, 2005 - 08:56 : matteo Ok, Steven, I'll rewrite the patch also for CVS.... Thanks Matteo ------------------------------------------------------------------------ January 24, 2005 - 11:16 : matteo Attachment: http://drupal.org/files/issues/taxonomy_nodetype_CVS.patch (4.05 KB) Here is the patch for Drupal CVS. I noticed the great addition of node_rewrite_sql... very powerful... I'm starting extensive testing on the patch, and I really woul like it to be added to core taxonomy, because it becomes a must for several sites... Matteo ------------------------------------------------------------------------ January 24, 2005 - 16:43 : moshe weitzman I'd rather see this done universally (not just for taxonomy urls) using the new sql rewrite capability. specifically, some code will implement the rewrite_sql hook and look for a querystring param &ntype=blog,story and then inject the proper WHERE clause. this will be very useful for tracker, home page, taxonomy urls, etc. -- View: http://drupal.org/node/12114 Edit: http://drupal.org/project/comments/add/12114

1 0

Re: [drupal-devel] Dealing with spam (was rel=nofollow)
by mike＠fuckingbrit.com 24 Jan '05

24 Jan '05

>All that is good, but introduces another problem: >If a spammer knows a filter or a subset of it, it is trivial to write >a generator for spam based on the filter. All that is being shared with the MT blacklist and the custom filters is regexes for domains. Spammers are spamming to promote web sites that sell something/make them money. Yes, they can alias a million domains to one site, so blocking one, and telling them how we block it means they move on to another. Sub-domains are free. But if they keep changing the url they are spamming, it screws their chances of getting a good google rating for it. They are then competing against every surviving post for their old domain. And their competitors. And legitimate sites of interest... If we use a /closed/ domain regex blacklist, then when they swap url each web of trust has to update individualy, and as pointed out, spammers will get onto lots of webs of trust. They'll blacklist their competitors (which actualy works to our advantage ;-)) to boost their chances of success. And work round the filters. If each WOT has to update itself on it's own, it'll take longer to cleanse the net of a new spam url. With a public system like the MT blacklist, one webmaster notices, updates his core site (if it's drupal powered that pushes out to all sites under his control, plus the sites of his friends and colleagues, which push out to...) and notifies the master list. Other sites read the updates regularly and then blacklist it themselves. It's a fast way of rushing a block to everywhere. Speed is the key with this, not privacy. If spammers learn that when they spam a new url, a baysian filter will pick up their spam message, generate a regex, notify a core, which will notify all other sites, which will then block it for the future, and remove it in the past... then url spamming this kind will eventualy die. Pipe dream? Yes, it's a war and the spammers are as resourceful and organised as the CMS/Blog engine developers. They'll find a new way to spam. But with a bit of luck, it won't involve comment/http-referer attacks. Cheers, Mike -------------------------------------------------------------------- mail2web - Check your email from the web at http://mail2web.com/ .

6 9

[drupal-devel] [task] Better default workflow
by Dries 24 Jan '05

24 Jan '05

Project: Drupal Version: cvs Component: node system Category: tasks Priority: normal Assigned to: drumm Reported by: drumm Updated by: Dries Status: patch I'm OK with this patch. It is a clear improvement (even though there is room for more). Dries Previous comments: ------------------------------------------------------------------------ December 10, 2004 - 04:27 : drumm Attachment: http://drupal.org/files/issues/types1.png (8.05 KB) This is a screenshot of the page replacing the 'default workflow.' ------------------------------------------------------------------------ December 10, 2004 - 04:29 : drumm Attachment: http://drupal.org/files/issues/types2.png (18.41 KB) This is what you get by clicking 'configure.' ------------------------------------------------------------------------ December 10, 2004 - 05:01 : drumm Attachment: http://drupal.org/files/issues/default_workflow.diff (10.79 KB) The default workflow page quickly becomes usuable as modules are added. I think it works much better broken up into one page per content type. This is a very basic patch which simply moves around the UI and does not change any functionality. I see lots of potential in following this path: * The submission guidelines would make sense on this page. Have the node module put those in, no need to have it duplicated in all the modues. * This page could be moved around to be a top level admin menu with local tasks 'list' and 'add new type' for making lightweight types on the fly instead of the very lightweight modules we have now. * Permissions for who can create nodes or edit their own might make sense on or next to these pages. * The various elements of the create content form, or even the node view, could be reordered with weights. This requires modules implementing hook_nodeapi('settings') to return strings containing the form elements instead of associative arrays. ------------------------------------------------------------------------ December 10, 2004 - 05:09 : moshe weitzman Perhaps we could preserve the overview of all node types and settings in read only table view. then an edit click would lead to the form you show. i think the overview of all settings at once is useful sometimes. ------------------------------------------------------------------------ December 10, 2004 - 10:35 : Dries This is a step in the right direction but the patch needs to evolve a bit before it is commit-worthy. For one, I would use form_group() rather than a form_item-hack. For consistency, table headers should start with a capital letter. Furthermore, I support the idea of creating a more prominent workflow-menu. Moving the story and forum settings to this page, might make sense, although I'm not sure people expect to find the 'submission guidelines' or 'forum structure settings' under 'workflow'. I guess it would work. Either way, this patch has potential so keep working on it. ------------------------------------------------------------------------ December 10, 2004 - 17:57 : tostinni Is this : Configure Workflow by roles [1] could be a way of improvement to ? Good ideas for the patch, thanks. [1] http://drupal.org/node/13129 ------------------------------------------------------------------------ December 17, 2004 - 00:22 : Dries The statistics module's "Display node counter" setting could be part of the workflow system (that or it should be added to the theme's "Toggle display" settings). Similarly, the "Display post information on" setting on the global theme configuration page might be better of being part of the workflow system. ------------------------------------------------------------------------ December 17, 2004 - 11:55 : Bèr Kessels Display and rendering setings should always be part of the theme settings, and preferably only the global settings. they have nothing to do with workflow, and will confuse people if they are "hidden"there. Similar to the "permissions" for upload, that are (were?) hidden there, since uploading has little to do with "allowing uploads". ------------------------------------------------------------------------ January 21, 2005 - 02:26 : drumm Attachment: http://drupal.org/files/issues/default_workflow_0.diff (16.22 KB) Here is a cleaned up patch which: - Capitalizes the column headers - Uses form_checkboxes() instead of the form_item() hack Because I wanted to use form_checkboxes() rather than a form_group() I had to make those 5 variables into one array. There is an update to set the one variable per node type to the values of the five old ones, and delete the five. I have not benchmarked the difference of one array per node type in the variables table vs. five booleans (ints) per node type, but I expect it might be faster. I do have more ideas for what should be done once this first step is finished. - I think 'content types' should be a menu item in the navigation menu, not a local task. This will let us put a 'add content type' tab in the logical place when/if it is time to do that. Also this page is buried now. - I think that the submission guidelines and minimum words should go on these pages. - I think form_group() should be used once the form grows. We could stick what we have now in a 'Workflow' fieldset. - I think that the 'settings' $op of hook_nodeapi() should be rethought and maybe put in another hook. - I think that node create/edit permissions could go on these pages. - I think that this form should have a 'save' $op and use system_settings_save() because that limits what modules can do to using variables. - I think that there should be a 'validate' $op so modules can do validation. - I think that the five options should be rethought. However, these are all separate issues which should have their own patches and debate and many will have to wait until 4.7. But this gets the door open for modules and ideas in 4.6. I'm willing to put more in the overview table, but I would like input on what it should look like to avoid width problems and be as usable as possible moving forward. Perhaps that should wait for another patch? ------------------------------------------------------------------------ January 21, 2005 - 02:32 : drumm BTW, I consider the added 'else' in system.module to be a bugfix. I'm not exactly sure why system_settings_save() does a drupal_goto(), but it helps make the form act a lot more predictably if it does the same type of returning or goto for whichever button is pressed. ------------------------------------------------------------------------ January 22, 2005 - 11:28 : stefan nagtegaal Wow, i really like this patch! This implementation is very clean and looks consistant with the way the input format's are configured. (Which is imo one of the best UI we have.) +1 for this.. ------------------------------------------------------------------------ January 23, 2005 - 19:33 : stefan nagtegaal Dries, what does this patch need more before you commit this? This is an improvement qua consistency, it gives us more space to use the nodeapi, AND it is very, very clean.. A big +1 again for this patch... ------------------------------------------------------------------------ January 23, 2005 - 21:28 : jvandyk While I think this patch is a good step forward over what currently exists, the name 'default workflow' is misleading. Really what these settings do is to set initial preferences for built-in Drupal node states, called 'options'. So +1 for this patch. In the future we should look towards the integration of content settings with flexible content types and real workflow [2]. [2] http://drupal.org/project/workflow -- View: http://drupal.org/node/14170 Edit: http://drupal.org/project/comments/add/14170

1 0

[drupal-devel] [feature] Testers needed: Node Type filtering in taxonomy on Drupal 4.5
by moshe weitzman 24 Jan '05

24 Jan '05

Project: Drupal Version: cvs Component: taxonomy.module Category: feature requests Priority: normal Assigned to: matteo Reported by: matteo Updated by: moshe weitzman Status: patch I'd rather see this done universally (not just for taxonomy urls) using the new sql rewrite capability. specifically, some code will implement the rewrite_sql hook and look for a querystring param &ntype=blog,story and then inject the proper WHERE clause. this will be very useful for tracker, home page, taxonomy urls, etc. moshe weitzman Previous comments: ------------------------------------------------------------------------ October 25, 2004 - 16:20 : matteo Attachment: http://drupal.org/files/issues/taxonomy_nodetype_filter.patch (5.46 KB) The attached fix wants to add a new feature to taxonomy.module: the ability to filter data also on node types. This is a need when you have to share one vocabulary between multiple node types. One example is the vocabulary 'Geography', containing all Cities and Regions. You could have events, stories and other custom made node types, sharing this vocabulary. The need arises when you want to see only events of a certain region; if you filter only on region, you'll see also stories and the other custom node types. The new syntax is the following: taxonomy/term/term1,term2,term3(nodetype1,nodetype2)/........ to filter based on three terms (in OR each others) and on two different node types or taxonomy/term/term1+term2+term3(nodetype1,nodetype2)/........ to filter based on three terms (in AND each others) and on two different node types The rest of the syntax for taxonomy/term remains the same, and the patch works also for taxonomy feed. Node types are tested for validity. You can specify one or more node types; if you omit node types, normal term filtering is issued. Feedbacks and help testing this patch is needed; personally, I think this would improve temendously taxonomy functionalities, and hope this will be committed to Drupal core. Feel free to contact me by mail: m dot ferrari at tiscali dot it Matteo ------------------------------------------------------------------------ October 25, 2004 - 16:25 : moshe weitzman see http://drupal.org/node/5040 ------------------------------------------------------------------------ October 25, 2004 - 16:46 : matteo I agree with you that this is an old story, but nothing has been committed to 4.5, that introduced also a new taxonomy syntax. My patch has also some pluses: - it is specific for 4.5 and takes care of the new taxonomy syntax - it lets you specify multiple node types - syntax is clean Matteo ------------------------------------------------------------------------ January 19, 2005 - 17:05 : robclay Will this work with 4.5.2? If so - I am looking for exactly this funcionality! ------------------------------------------------------------------------ January 20, 2005 - 00:43 : matteo I'll work on a port for 4.5.2 hopefully next week... I'll keep you informed. Matteo ------------------------------------------------------------------------ January 23, 2005 - 18:19 : matteo Attachment: http://drupal.org/files/issues/taxonomy_nodetype_452.patch (4.43 KB) Here is the patch that adds nodetype filtering capabilities to 4.5.2 taxonomy module. Syntax is backwards compatible, so if you plan not to use node type filtering, syntax does not change at all. (see previous postings in this thread) I would need extensive testing and feedback... and hope this functionality will be included into Drupal core. Matteo ------------------------------------------------------------------------ January 23, 2005 - 18:38 : Steven New features only get added to the HEAD branch... you'll have to update your patch. ------------------------------------------------------------------------ January 24, 2005 - 01:56 : matteo Ok, Steven, I'll rewrite the patch also for CVS.... Thanks Matteo ------------------------------------------------------------------------ January 24, 2005 - 04:16 : matteo Attachment: http://drupal.org/files/issues/taxonomy_nodetype_CVS.patch (4.05 KB) Here is the patch for Drupal CVS. I noticed the great addition of node_rewrite_sql... very powerful... I'm starting extensive testing on the patch, and I really woul like it to be added to core taxonomy, because it becomes a must for several sites... Matteo -- View: http://drupal.org/node/12114 Edit: http://drupal.org/project/comments/add/12114

1 0

[drupal-devel] looking for text/RSS data
by Vladimir Zlatanov 24 Jan '05

24 Jan '05

I'm working on a set of text classification algorithms. They are extremely experimental at the moment. I have the basics covered. If useful the code will end up in contrib. I want to use them for automatic classification of RSS feed items to a taxonomy. To test the algorithms and see what and how to improve on them I need to get access to some well classified text data - preferably drupal based. Can anyone share their db or a part of, so I can try and run the tests. The websites, which started me on this path are too plain for the time being to use them as guinea pigs. I would prefer to run the tests on some isolated machines in here, so I can measure the performance and run some more elaborate statistics, which while useful, will definitely bring an average web server to crawl. Thanks, Vlado

1 0

Re: [drupal-devel] Dealing with spam (was rel=nofollow)
by mike＠fuckingbrit.com 24 Jan '05

24 Jan '05

>That was ecactly my concern and idea. I found that on all my sites that were >hit by spam (the five sites I maintain) the spam was exactly the same. My >most popular of the five was hit first. But the other four had to be learned >to handle the *exact same spam messages*. I'm being increasingly convinced by the idea of sharing spam as a feed. I've started step one of the process, which is importing the MT blacklist. This has a similar effect I think to sharing the spam. And is an easy first step as the infrastructure (i.e. the central blacklist and update feeds) already exists. I'm about 90% through coding the module (just got to do the actual insert and delete. And check it all works, this is only my second module and the first was only two hooks...). The second step is a second module. I'm thinking this should: 1) Provide an MT masterlist format (all their formats) feed of all MT items the site knows. 2) Provide a feed of all spam_custom entries in an RSS (based) feed. 3) Provide a feed of all spam_token entries in an RSS (based) feed. 4) Provide a feed of all trapped spam in an RSS feed. 5) Provide an XML-RPC push/pull mechanism for harvesting the above information. 6) Provide the ability to turn on/off each of the above. 7) Provide the ability to require a specific permission for each of the above. I'm still not certain of the need to keep any of the first 4 items as secured private things. Keeping them open allows us to easily share with everyone. But, if the module allows public and private sharing then it doesn't matter and can work for everyone. I really am not going to start the second module until I've migrated. Mike -------------------------------------------------------------------- mail2web - Check your email from the web at http://mail2web.com/ .

2 2

[drupal-devel] [bug] Book module 'printer friendly' functions do not calll some filters
by matteo 24 Jan '05

24 Jan '05

Project: Drupal Version: 4.5.2 Component: book.module Category: bug reports Priority: normal Assigned to: matteo Reported by: matteo Updated by: matteo Status: patch Attachment: http://drupal.org/files/issues/book_nodeapi.patch (937 bytes) Some filters (for example inline.module) rendered through nodeapi hook are not working due to missing call to nodeapi, when you user book/printer friendly function. this occurs also in previous Drupal versions. Attached there is a patch that seems working. Matteo matteo -- View: http://drupal.org/node/15948 Edit: http://drupal.org/project/comments/add/15948

1 1