July 2005 - Development - lists.drupal.org

[drupal-devel] [bug] Do not allow anonymous comment info editing if disabled
by Goba 19 Jul '05

19 Jul '05

Issue status update for http://drupal.org/node/26516 Post a follow up: http://drupal.org/project/comments/add/26516 Project: Drupal Version: 4.6.2 Component: comment.module Category: bug reports Priority: normal Assigned to: Goba Reported by: Goba Updated by: Goba Status: patch Attachment: http://drupal.org/files/issues/Drupal.anonymous-comment-edit.patch (813 bytes) The comment_admin_edit() admin editing interface allows the admin to edit anonymous comment sender properties, but this option is also provided when this feature is explicitly disabled on the settings page, and such info should not be stored. The attached patch checks if the option is not disabled and only allows editing in that case. This is also a bug in DRUPAL HEAD. Goba

3 3

[drupal-devel] [task] More improvements to help text on access control pages
by nysus 19 Jul '05

19 Jul '05

Issue status update for http://drupal.org/node/27073 Post a follow up: http://drupal.org/project/comments/add/27073 Project: Drupal Version: cvs Component: user.module Category: tasks Priority: minor Assigned to: nysus Reported by: nysus Updated by: nysus Status: patch Attachment: http://drupal.org/files/issues/user_21.patch (3.84 KB) Here's another patch with changes similar to those found on http://drupal.org/node/27062 nysus

1 0

[drupal-devel] [bug] Nodes are repeated when asking for a list of taxonomy/term/x, y nodes
by matteo 19 Jul '05

19 Jul '05

Issue status update for http://drupal.org/node/26683 Post a follow up: http://drupal.org/project/comments/add/26683 Project: Drupal Version: 4.6.2 Component: taxonomy.module Category: bug reports Priority: critical Assigned to: matteo Reported by: matteo Updated by: matteo Status: patch Attachment: http://drupal.org/files/issues/taxonomy_distinct_part2.patch (974 bytes) Nodes are repeated when asking for terms in or each other (ex. term 25 or term 27). same symptoms as http://drupal.org/node/22469, where the problem appeared only when dealing with terms in 'and'. the attached patch solves the problem, due to the erroneous elimination of the distinct clause in the query issued for 'or' terms. Same problem occurs also in Drupal 4.6.0 and Drupal 4.6.1. Matteo matteo

4 4

[drupal-devel] [feature] Patch to add the guid tag to the rss feed
by Dries 19 Jul '05

19 Jul '05

Issue status update for http://drupal.org/node/26223 Post a follow up: http://drupal.org/project/comments/add/26223 Project: Drupal Version: cvs Component: node system Category: feature requests Priority: normal Assigned to: Anonymous Reported by: frjo Updated by: Dries Status: patch guid has to be permanent. I don't think we can guarantuee that at the moment. People can set URL aliases and stuff, and these changes would change the guid. Dries Previous comments: ------------------------------------------------------------------------ Sat, 02 Jul 2005 07:29:30 +0000 : frjo Attachment: http://drupal.org/files/issues/common_rss_guid.patch (537 bytes) This patch add the guid (globally unique identifier) tag to the rss feed. This is in line with the RSS 2.0 Specification, se below. It's a very simpel, one line patch, to the format_rss_item function in common.inc. I want this personally so my news reader (NetNewsWire) can distinguish between new and updates posts. >From http://blogs.law.harvard.edu/tech/rss "A frequently asked question about s is how do they compare to s. Aren't they the same thing? Yes, in some content systems, and no in others. In some systems, is a permalink to a weblog item. However, in other systems, each is a synopsis of a longer article, points to the article, and is the permalink to the weblog entry. In all cases, it's recommended that you provide the guid, and if possible make it a permalink. This enables aggregators to not repeat items, even if there have been editing changes. " ------------------------------------------------------------------------ Tue, 19 Jul 2005 06:09:38 +0000 : frjo Attachment: http://drupal.org/files/issues/common_rss_guid_02.patch (524 bytes) I made a patch for the cvs version of Drupal also. I believe this is a smal but very nice improvement of Drupals RSS support.

1 0

[drupal-devel] [task] Improvement to help text on "access control" page
by nysus 19 Jul '05

19 Jul '05

Issue status update for http://drupal.org/node/27062 Post a follow up: http://drupal.org/project/comments/add/27062 Project: Drupal Version: 4.6.0 Component: user.module Category: tasks Priority: minor Assigned to: nysus Reported by: nysus Updated by: nysus Status: patch Attachment: http://drupal.org/files/issues/user_19.patch (2.22 KB) Improves readability; gets rid of technical jargon; provides concrete example; provides suggestions for how permissions can be used. See attached. nysus

1 1

[drupal-devel] [feature] 'View terms' for vocabularies with > 25 terms
by Morbus Iff 19 Jul '05

19 Jul '05

Issue status update for http://drupal.org/node/20505 Project: Drupal Version: cvs Component: taxonomy.module Category: feature requests Priority: normal Assigned to: Morbus Iff Reported by: Morbus Iff Updated by: Morbus Iff Status: patch Attachment: http://drupal.org/files/issues/_p_25termvocab.patch (1.28 KB) There was some small talk about this here and there during my folksonomy/free tagging patch, but I held off until now to actually implement it. Much like we handle free tagging vocabularies ("this is a free tagging vocabulary: view terms", which leads the admin into the taxonomy pager system), this patch does the same thing for NON-free tagging vocabularies, but ONLY if the vocabulary has more than 25 terms. These patches were made during the exploration and customization of Drupal by http://www.NHPR.org. In loving support of open source software, http://www.NHPR.org will continue to contribute patches they feel the community will benefit from. Questions about this patch should be directed to morbus(a)disobey.com. Morbus Iff

7 23

[drupal-devel] [bug] blogapi.module bug
by nysus 19 Jul '05

19 Jul '05

Issue status update for http://drupal.org/node/27059 Post a follow up: http://drupal.org/project/comments/add/27059 Project: Drupal Version: cvs Component: blogapi.module Category: bug reports Priority: critical Assigned to: Anonymous Reported by: nysus Updated by: nysus Status: patch Attachment: http://drupal.org/files/issues/blogapi_2.patch (728 bytes) An improper argument in the blogapi.module is causing errors. Patch attached. nysus

1 0

[drupal-devel] [bug] node_search doesn't node_view, causing bad snippets.
by Morbus Iff 19 Jul '05

19 Jul '05

Issue status update for http://drupal.org/node/26458 Post a follow up: http://drupal.org/project/comments/add/26458 Project: Drupal Version: cvs Component: node.module Category: bug reports Priority: normal -Assigned to: Anonymous +Assigned to: Morbus Iff Reported by: Morbus Iff Updated by: Morbus Iff -Status: active +Status: patch Attachment: http://drupal.org/files/issues/_p_26458_nodesearch.patch (996 bytes) Updated for HEAD. Morbus Iff Previous comments: ------------------------------------------------------------------------ Wed, 06 Jul 2005 15:08:32 +0000 : Morbus Iff Attachment: http://drupal.org/files/issues/_p_nodesearch.patch (1010 bytes) During search indexing, the node.module invokes node_view and node view api before indexing it for content (see node_update_index). This, however, doesn't happen on node_search, which assumes that the body exists to get a snippet from. This causes an empty snippet on flexinode nodes, or anything else that requires a node view api. This patch simply adds the same block from node_update_index to node_search.

1 0

[drupal-devel] [feature] Allow annoymous users to log in on access denied
by Kobus 19 Jul '05

19 Jul '05

Issue status update for http://drupal.org/node/24050 Post a follow up: http://drupal.org/project/comments/add/24050 Project: Drupal Version: cvs Component: user system Category: feature requests Priority: normal Assigned to: gordon Reported by: gordon Updated by: Kobus Status: patch In concept, a definitive +1 from me. Especially the mention that the login box does not even display unless the user has to log in. I have started to remove the block completely and put it in a menu somewhere else so that it is not so obtrusive. For a commercial site, the exaggerated login page makes it look "as if you have something to hide". Not good. Regards, Kobus Previous comments: ------------------------------------------------------------------------ Wed, 01 Jun 2005 05:51:25 +0000 : gordon Attachment: http://drupal.org/files/issues/denied_login.diff (1.41 KB) If the user is anonymous, then the user will be presented with the login page 'user/login' instead of a the 403 default page. If the user then logins in and has access to the page they will then get redirected to the page they were trying to access. If the user is already logged in then they will get the defined 403 page. With the standard system you cannot just set user/login as the 403 page as you will not be redirected to the page that you were originally requesting, but instead to the user page. ------------------------------------------------------------------------ Sun, 05 Jun 2005 00:22:06 +0000 : gordon Attachment: http://drupal.org/files/issues/denied_login2.patch (3.43 KB) here is a newer version of the patch which adds an option to admin/settings page so this functionality can be turned off and on. ------------------------------------------------------------------------ Sun, 05 Jun 2005 01:38:39 +0000 : moshe weitzman I have been wanting this since i first saw drupal (i.e. a long time). +1 ------------------------------------------------------------------------ Sun, 05 Jun 2005 10:29:05 +0000 : Dries Because the 403 page is configurable, this is already possible. This patch only makes it more convenient. I tempted to say: "Won't commit, but let's extend the form description a bit so it is clear this is possible.". That or we add a link to the login page (without the extra setting), cfr. to what the comment module does. ------------------------------------------------------------------------ Sun, 05 Jun 2005 12:06:40 +0000 : moshe weitzman dries - upon executing the 403 handler, the original $_GET['q'] is lost. That means that we cannot redirect to the destination page after login and thats one of the main benefits of this patch. ------------------------------------------------------------------------ Sun, 05 Jun 2005 12:40:57 +0000 : gordon Yes you can use the user/login link, but once you login you get the user page and not the page you were triing to get to. Also if you are logged in you will still get the user/login page when really you should get the custom access denied page. ------------------------------------------------------------------------ Sun, 05 Jun 2005 20:57:20 +0000 : slower What version of Drupal is this for? I'm using 4.5. ------------------------------------------------------------------------ Sun, 05 Jun 2005 23:47:19 +0000 : gordon It is for cvs (4.7) I would have to rewrite it if I was to port it back to 4.5 ------------------------------------------------------------------------ Mon, 13 Jun 2005 23:49:02 +0000 : gordon Dries, What is the verdict on this patch. I have found no way of prompting anonymous users to login and continue seemlessly without this patch. Please correct me if I am wrong, as this is some functionality that I require. ------------------------------------------------------------------------ Tue, 14 Jun 2005 01:00:12 +0000 : neofactor Glad to see it... I had always just added the following custom pages: http://neofactor.com/error403 (with a login link) http://neofactor.com/error404 (Adding the auto search) My 403's are only for non-members and all members have the same access. I use PHP to control groups differently for lots of different clients, so this works out well form me. The auto redirect function is nice.... keeping the user's initial request in place. hey.... When is Drupal going to add images to pages at core? Visual appeal.... It would be great if menu items and other areas started to do this... then people could just swap them out. Just a wish list. ;) ------------------------------------------------------------------------ Tue, 14 Jun 2005 03:02:01 +0000 : gordon Just adding the pages does work, but does not give the effect that I need. You can always use the login box on the sidebar, which will do the same thing. You said that the 403's aren't used to logged in users as they have the same privledge, But not everyone has the same privledge on your site (unless everyone has the same rights as user 1 ;-)) So what if a user who is already logged in goes to /admin you do not want to tell them that they need to login to get to the admin page, you want to send them to a big go away page. ------------------------------------------------------------------------ Tue, 19 Jul 2005 11:34:19 +0000 : jjeff Before I saw this thread, I posted another take on this bug at http://drupal.org/node/26659. It explains the problem a little more in-depth. Here's the thing: What makes Drupal sites look like Drupal sites is that they've got a login/password box on every page until the user is logged in. For Drupal to become a mature platform, it's going to need to move away from dependence on this crutch. Drupal should provide the infrastructure to allow the option of a simple "Login/Register" link. However, if a user gets an access denied message, they should be prompted to log in. As it is, the best that you can do after login is direct them back to the node that defines the "Access Denied" message. This is more than just confusing for the user. It's downright wrong! Dries, please reconsider this patch and/or some variation that solves this problem. It is essential for all current versions of Drupal. Thanks, Jeff

1 0

[drupal-devel] [feature] Allow annoymous users to log in on access denied
by jjeff 19 Jul '05

19 Jul '05

Issue status update for http://drupal.org/node/24050 Post a follow up: http://drupal.org/project/comments/add/24050 Project: Drupal Version: cvs Component: user system Category: feature requests Priority: normal Assigned to: gordon Reported by: gordon Updated by: jjeff Status: patch Before I saw this thread, I posted another take on this bug at http://drupal.org/node/26659. It explains the problem a little more in-depth. Here's the thing: What makes Drupal sites look like Drupal sites is that they've got a login/password box on every page until the user is logged in. For Drupal to become a mature platform, it's going to need to move away from dependence on this crutch. Drupal should provide the infrastructure to allow the option of a simple "Login/Register" link. However, if a user gets an access denied message, they should be prompted to log in. As it is, the best that you can do after login is direct them back to the node that defines the "Access Denied" message. This is more than just confusing for the user. It's downright wrong! Dries, please reconsider this patch and/or some variation that solves this problem. It is essential for all current versions of Drupal. Thanks, Jeff jjeff Previous comments: ------------------------------------------------------------------------ Wed, 01 Jun 2005 05:51:25 +0000 : gordon Attachment: http://drupal.org/files/issues/denied_login.diff (1.41 KB) If the user is anonymous, then the user will be presented with the login page 'user/login' instead of a the 403 default page. If the user then logins in and has access to the page they will then get redirected to the page they were trying to access. If the user is already logged in then they will get the defined 403 page. With the standard system you cannot just set user/login as the 403 page as you will not be redirected to the page that you were originally requesting, but instead to the user page. ------------------------------------------------------------------------ Sun, 05 Jun 2005 00:22:06 +0000 : gordon Attachment: http://drupal.org/files/issues/denied_login2.patch (3.43 KB) here is a newer version of the patch which adds an option to admin/settings page so this functionality can be turned off and on. ------------------------------------------------------------------------ Sun, 05 Jun 2005 01:38:39 +0000 : moshe weitzman I have been wanting this since i first saw drupal (i.e. a long time). +1 ------------------------------------------------------------------------ Sun, 05 Jun 2005 10:29:05 +0000 : Dries Because the 403 page is configurable, this is already possible. This patch only makes it more convenient. I tempted to say: "Won't commit, but let's extend the form description a bit so it is clear this is possible.". That or we add a link to the login page (without the extra setting), cfr. to what the comment module does. ------------------------------------------------------------------------ Sun, 05 Jun 2005 12:06:40 +0000 : moshe weitzman dries - upon executing the 403 handler, the original $_GET['q'] is lost. That means that we cannot redirect to the destination page after login and thats one of the main benefits of this patch. ------------------------------------------------------------------------ Sun, 05 Jun 2005 12:40:57 +0000 : gordon Yes you can use the user/login link, but once you login you get the user page and not the page you were triing to get to. Also if you are logged in you will still get the user/login page when really you should get the custom access denied page. ------------------------------------------------------------------------ Sun, 05 Jun 2005 20:57:20 +0000 : slower What version of Drupal is this for? I'm using 4.5. ------------------------------------------------------------------------ Sun, 05 Jun 2005 23:47:19 +0000 : gordon It is for cvs (4.7) I would have to rewrite it if I was to port it back to 4.5 ------------------------------------------------------------------------ Mon, 13 Jun 2005 23:49:02 +0000 : gordon Dries, What is the verdict on this patch. I have found no way of prompting anonymous users to login and continue seemlessly without this patch. Please correct me if I am wrong, as this is some functionality that I require. ------------------------------------------------------------------------ Tue, 14 Jun 2005 01:00:12 +0000 : neofactor Glad to see it... I had always just added the following custom pages: http://neofactor.com/error403 (with a login link) http://neofactor.com/error404 (Adding the auto search) My 403's are only for non-members and all members have the same access. I use PHP to control groups differently for lots of different clients, so this works out well form me. The auto redirect function is nice.... keeping the user's initial request in place. hey.... When is Drupal going to add images to pages at core? Visual appeal.... It would be great if menu items and other areas started to do this... then people could just swap them out. Just a wish list. ;) ------------------------------------------------------------------------ Tue, 14 Jun 2005 03:02:01 +0000 : gordon Just adding the pages does work, but does not give the effect that I need. You can always use the login box on the sidebar, which will do the same thing. You said that the 403's aren't used to logged in users as they have the same privledge, But not everyone has the same privledge on your site (unless everyone has the same rights as user 1 ;-)) So what if a user who is already logged in goes to /admin you do not want to tell them that they need to login to get to the admin page, you want to send them to a big go away page.

1 0