August 2005 - Development - lists.drupal.org

[drupal-devel] [task] Remove /view from user links on search
by drumm 04 Aug '05

04 Aug '05

Issue status update for http://drupal.org/node/28154 Post a follow up: http://drupal.org/project/comments/add/28154 Project: Drupal Version: cvs Component: user.module Category: tasks Priority: minor Assigned to: drumm Reported by: drumm Updated by: drumm Status: patch (code needs review) Attachment: http://drupal.org/files/issues/user.module_16.diff (829 bytes) Don't need that /view on the end of the url. drumm

1 0

[drupal-devel] [bug] Statistic information about node reads is shown to unprivileged users
by Robin Monks 03 Aug '05

03 Aug '05

Issue status update for http://drupal.org/node/22565 Post a follow up: http://drupal.org/project/comments/add/22565 Project: Drupal Version: cvs Component: statistics.module Category: bug reports Priority: normal Assigned to: Robin Monks Reported by: massabob Updated by: Robin Monks Status: patch (ready to be committed) /the term "access statistics counter" doesn't tell me anything. The counters are for posts -- I think that should be reflected in the permission's name. / Suggestions: view node access counter view node view counter access node view counter view node hit counter I rather like "view node access counter". Dries, would this satisify you? /Is this different from the 'Count content views' setting?/ Yes, on two counts. * These permissions are for users, not for admins. The count content views setting changes both * This setting lets the administrator choose specific groups to see the counter (eg, moderators, or only registered users) Robin Robin Monks Previous comments: ------------------------------------------------------------------------ Wed, 11 May 2005 07:51:40 +0000 : massabob Information about '%count reads' in node's footer is shown to unprivileged users. I suggest that function statistics_link in statistics.module should be corrected in this way: // Original function statistics_link($type, $node = 0, $main = 0) { global $id; $links = array(); if ($type != 'comment' && variable_get('statistics_display_counter', 0)) { $statistics = statistics_get($node->nid); if ($statistics) { $links[] = format_plural($statistics['totalcount'], '1 read', '%count reads'); } } return $links; } // Fixed function statistics_link($type, $node = 0, $main = 0) { global $id; $links = array(); if ($type != 'comment' && variable_get('statistics_display_counter', 0) && user_access('display statistics')) { $statistics = statistics_get($node->nid); if ($statistics) { $links[] = format_plural($statistics['totalcount'], '1 read', '%count reads'); } } return $links; } The only change is in "&& user_access('display statistics')" on line 98. ------------------------------------------------------------------------ Fri, 27 May 2005 01:44:25 +0000 : RobRoy Should read user_access('access statistics') not user_access('display statistics'). ------------------------------------------------------------------------ Fri, 27 May 2005 11:19:36 +0000 : Robin Monks Attachment: http://drupal.org/files/issues/user.access.stats.patch (730 bytes) And here that is in patch form. Robin ------------------------------------------------------------------------ Wed, 01 Jun 2005 04:09:16 +0000 : Steven I'm not sure about this patch: often, read counts are shown directly on the site. But if the permission for viewing the counts is the same as the permission for accessing the administrator's detailed logs, then you wouldn't give that to everyone. There is already an option to choose whether counts are displayed. Perhaps we could change that to "No" "For priviledged users" "For everyone". In last case it acts like it is now, it the second case it requires "access statistics" permission. What do you think? ------------------------------------------------------------------------ Wed, 01 Jun 2005 14:13:54 +0000 : Robin Monks Sounds good to me. I'll try to code something up for this. Robin ------------------------------------------------------------------------ Thu, 09 Jun 2005 13:55:49 +0000 : Robin Monks Attachment: http://drupal.org/files/issues/authstats.patch (2.26 KB) Here is the patch. Uses a switch to choose between signed in users, all users, users with permissions or noone. Robin ------------------------------------------------------------------------ Thu, 09 Jun 2005 14:08:16 +0000 : Robin Monks I tested this patch with various settings on my local install and it worked fine. Robin ------------------------------------------------------------------------ Thu, 09 Jun 2005 16:30:25 +0000 : Bèr Kessels Is there a reason why you check for $user->uid? Whaen someone has "access statistics" set to anonymous users, your check for $user->uid will override taht settings. Not good IMO. <?php $group .= form_radios(t('Display counter values'), 'statistics_display_counter', variable_get('statistics_display_counter', 0), array('1' => t('For all users'), '2' => t('For authenticated users'), '3' => t('For priviledged users'), '0' => t('Disabled')), t('Display how many times given content has been viewed.')); ?> is very inconsistent. please use *only* the permissions page to set permissions, and do not create new permissions-alike settings in any configuration pages. I would say a simple check for user_access('access statistics') will do the trick ------------------------------------------------------------------------ Thu, 09 Jun 2005 16:32:53 +0000 : Bèr Kessels sorry, i meant to say user_access('access statistics counter'), not user_access('access statistics'). We already have "access statistics'" an additional "access statistics counter" for showing users the counter should work Ber ------------------------------------------------------------------------ Thu, 09 Jun 2005 16:49:48 +0000 : Robin Monks Attachment: http://drupal.org/files/issues/statistics.module (23.1 KB) OK, here is a patch to that end... Robin ------------------------------------------------------------------------ Thu, 09 Jun 2005 17:00:50 +0000 : Robin Monks Attachment: http://drupal.org/files/issues/authstats_0.patch (1 KB) Um, let's just pretend I didn't just upload the entire stats module. OK? OK! Robin ------------------------------------------------------------------------ Thu, 09 Jun 2005 17:05:59 +0000 : Robin Monks Attachment: http://drupal.org/files/issues/authstats_1.patch (1.06 KB) Hotfix. Robin ------------------------------------------------------------------------ Thu, 09 Jun 2005 17:11:23 +0000 : Robin Monks Attachment: http://drupal.org/files/issues/authstats_2.patch (1.11 KB) Hopefuly the final version. Thanks to chx and berkes for pulling it apart ;-) Robin ------------------------------------------------------------------------ Thu, 09 Jun 2005 17:21:38 +0000 : Bèr Kessels +1 for this patch. it adds functionality, but does not add clutter nor any config options. ------------------------------------------------------------------------ Fri, 10 Jun 2005 02:39:06 +0000 : frjo +1 I have implemented the patch authstats_2.patch on my site running Drupal 4.6.1 and it works well. ------------------------------------------------------------------------ Fri, 01 Jul 2005 08:10:22 +0000 : mfb +1 ------------------------------------------------------------------------ Fri, 01 Jul 2005 12:03:56 +0000 : Jose A Reyero +1 I tested the patch, works fine, and I'm always for "more options" ;-) ------------------------------------------------------------------------ Mon, 01 Aug 2005 21:17:48 +0000 : Junyor +1. Using this on my site now. ------------------------------------------------------------------------ Tue, 02 Aug 2005 21:53:15 +0000 : Robin Monks Attachment: http://drupal.org/files/issues/node_counter_permission.patch (2.97 KB) This patch revision removes the duplicate show counter option from the settings. Thanks UnConeD! Robin ------------------------------------------------------------------------ Wed, 03 Aug 2005 15:44:59 +0000 : Dries -1, the term "access statistics counter" doesn't tell me anything. The counters are for posts -- I think that should be reflected in the permission's name. Is this different from the 'Count content views' setting?

1 0

[drupal-devel] [feature] Trigger debug mode on-the-fly
by mathias 03 Aug '05

03 Aug '05

Issue status update for http://drupal.org/node/21379 Project: Drupal Version: cvs Component: other Category: feature requests Priority: normal Assigned to: Anonymous Reported by: mathias Updated by: mathias Status: patch Attachment: http://drupal.org/files/issues/devel_GET_params_core.patch (2.38 KB) This patch allows admins who are using devel.module to optionally toggle the page timer, query logger and page redirection for each request using GET parameters rather than navigating to admin/settings/devel and flipping the global settings back and forth. I added this since I usually don't need to print out this information for every page. Now I just use: http://example.com/index.php?q=node&dev_query=1 for the request I'm interested in. Two other params can also be toggled: dev_timer and dev_redirect. mathias

4 5

[drupal-devel] [bug] Always resizing user pictures breaks transparency?
by leafish_paul 03 Aug '05

03 Aug '05

Issue status update for http://drupal.org/node/24946 Project: Drupal Version: 4.6.1 Component: user.module Category: bug reports Priority: normal Assigned to: Anonymous Reported by: leafish_paul Updated by: leafish_paul Status: patch Attachment: http://drupal.org/files/issues/user.module_tweaked_picture_resizing.patch (1.47 KB) I recently noticed that when uploading transparent user pictures to a Drupal site, the transparent colour is lost (replaced with black). I think its to do with image_size()... but I noticed the slightly odd logic in user.module: <?php if (!$info || !$info['extension']) { form_set_error('picture', t('The uploaded file was not an image.')); } else if (image_get_toolkit()) { image_scale($file->filepath, $file->filepath, $maxwidth, $maxheight); } else if (filesize($file->filepath) > (variable_get('user_picture_file_size', '30') * 1000)) { form_set_error('picture', t('The uploaded image is too large; the maximum file size is %size kB.', array('%size' => variable_get('user_picture_file_size', '30')))); } else if ($info['width'] > $maxwidth || $info['height'] > $maxheight) { form_set_error('picture', t('The uploaded image is too large; the maximum dimensions are %dimensions pixels.', array('%dimensions' => variable_get('user_picture_dimensions', '85x85')))); } ?> So, the image is always scaled if an image toolkit is found. The attached patch /only/ scales user pictures if they are too large, and will still show an error if a toolkit is not found. I'm aware that there may be a better patch for image.inc to retain scaled image transparency? leafish_paul

2 2

[drupal-devel] [feature] Parse atom feeds
by Prometheus6 03 Aug '05

03 Aug '05

Issue status update for http://drupal.org/node/13941 Post a follow up: http://drupal.org/project/comments/add/13941 Project: Drupal Version: cvs Component: aggregator.module Category: feature requests Priority: normal Assigned to: Prometheus6 Reported by: Capnj Updated by: Prometheus6 Status: patch (code needs review) That would be for the Atom module. Prometheus6 Previous comments: ------------------------------------------------------------------------ Sun, 05 Dec 2004 23:26:00 +0000 : Capnj I've seen mention elsewhere on drupal.org but don't see a feature request, so here goes. The news aggregator is a great piece of Drupal as far as I'm concerned and I'd sure like to see it read all the sources out there, have the 'blog this' function, and also have a tool for browsers to generate a blog entry from a web page (like MT had). Is that a big enough request? LOL Thanks for all that everyone does here. Great stuff! gil ------------------------------------------------------------------------ Tue, 07 Dec 2004 17:38:31 +0000 : drumm RSS 2.0 feeds should work in 4.5.0 and earlier. ------------------------------------------------------------------------ Mon, 14 Feb 2005 16:04:32 +0000 : georgehotelling I've hacked Magpie [1] support into the Drupal aggregator, so it can support Atom. If you have a Drupal site and want the code, you can get it from http://george.hotelling.net/projects/magpie-aggregator-4.5.2.tgz [2] I'm not sure if I'm supposed to create a patch or what, but I needed this for ArborBlogs.com [3] and figured some other people would benefit from it. [1] http://magpierss.sourceforge.net/ [2] http://george.hotelling.net/projects/magpie-aggregator-4.5.2.tgz [3] http://www.arborblogs.com/ ------------------------------------------------------------------------ Tue, 15 Mar 2005 04:04:42 +0000 : Prometheus6 Attachment: http://drupal.org/files/issues/AGGREGATOR_ATOM_HEAD.txt (5.46 KB) Very nice. I hacked aggregator.module for 4.6 using your module as a guide...well, frankly by ripping out great chunks of code for my use. ------------------------------------------------------------------------ Thu, 28 Jul 2005 22:21:11 +0000 : Boris Mann Can someone roll a patch for this? Would be a good addition for 4.7 now that Atom is at 1.0. ------------------------------------------------------------------------ Fri, 29 Jul 2005 01:49:42 +0000 : Prometheus6 Attachment: http://drupal.org/files/issues/magpie_aggregator.zip (7.87 KB) A patch would require the Magpie include files and wholly restructures the way the feeds are parsed...the Magpie code would handle all the feeds, not just Atom. That said, the attached zip file has the necessary includes and a patch to CVS. ------------------------------------------------------------------------ Fri, 29 Jul 2005 03:36:59 +0000 : Steven Magpie RSS duplicates a lot of functionality that is already in Drupal. We decided a long time ago that we would not use it. Porting Atom parsing into the current aggregator can't be that hard. ------------------------------------------------------------------------ Mon, 01 Aug 2005 16:38:53 +0000 : Prometheus6 Attachment: http://drupal.org/files/issues/AGGREGATOR_ATOM_HEAD_0.txt (1.93 KB) Since I'm messing around with the aggregator module anyway... I developed this around Atom 0.3 feeds this weekend, but I don't see anything in Atom 1.0 that should break it. ------------------------------------------------------------------------ Tue, 02 Aug 2005 15:00:50 +0000 : Eaton +1 on that patch. Running it now on my test site and everything looks great. ------------------------------------------------------------------------ Tue, 02 Aug 2005 16:24:54 +0000 : Bèr Kessels a small issue, whe do not use if ($data) $items[$item][$tag] .= $data; please just use if ($data) { $items[$item][$tag] .= $data; } ------------------------------------------------------------------------ Wed, 03 Aug 2005 02:18:54 +0000 : Prometheus6 Attachment: http://drupal.org/files/issues/AGGREGATOR_ATOM_HEAD_1.txt (1.99 KB) Not a problem. Here's the corrections. ------------------------------------------------------------------------ Wed, 03 Aug 2005 16:14:14 +0000 : Dries If this is all it takes to parse Atom feeds (to some extend), I'm all for it. Code looks OK. Set to 'ready to be committed' after some testing. ------------------------------------------------------------------------ Wed, 03 Aug 2005 18:59:20 +0000 : kika anybody up for a testing suite tests? http://intertwingly.net/wiki/pie/FormatTests

1 0

[drupal-devel] [feature] Parse atom feeds
by kika 03 Aug '05

03 Aug '05

Issue status update for http://drupal.org/node/13941 Post a follow up: http://drupal.org/project/comments/add/13941 Project: Drupal Version: cvs Component: aggregator.module Category: feature requests Priority: normal Assigned to: Prometheus6 Reported by: Capnj Updated by: kika Status: patch (code needs review) anybody up for a testing suite tests? http://intertwingly.net/wiki/pie/FormatTests kika Previous comments: ------------------------------------------------------------------------ Sun, 05 Dec 2004 23:26:00 +0000 : Capnj I've seen mention elsewhere on drupal.org but don't see a feature request, so here goes. The news aggregator is a great piece of Drupal as far as I'm concerned and I'd sure like to see it read all the sources out there, have the 'blog this' function, and also have a tool for browsers to generate a blog entry from a web page (like MT had). Is that a big enough request? LOL Thanks for all that everyone does here. Great stuff! gil ------------------------------------------------------------------------ Tue, 07 Dec 2004 17:38:31 +0000 : drumm RSS 2.0 feeds should work in 4.5.0 and earlier. ------------------------------------------------------------------------ Mon, 14 Feb 2005 16:04:32 +0000 : georgehotelling I've hacked Magpie [1] support into the Drupal aggregator, so it can support Atom. If you have a Drupal site and want the code, you can get it from http://george.hotelling.net/projects/magpie-aggregator-4.5.2.tgz [2] I'm not sure if I'm supposed to create a patch or what, but I needed this for ArborBlogs.com [3] and figured some other people would benefit from it. [1] http://magpierss.sourceforge.net/ [2] http://george.hotelling.net/projects/magpie-aggregator-4.5.2.tgz [3] http://www.arborblogs.com/ ------------------------------------------------------------------------ Tue, 15 Mar 2005 04:04:42 +0000 : Prometheus6 Attachment: http://drupal.org/files/issues/AGGREGATOR_ATOM_HEAD.txt (5.46 KB) Very nice. I hacked aggregator.module for 4.6 using your module as a guide...well, frankly by ripping out great chunks of code for my use. ------------------------------------------------------------------------ Thu, 28 Jul 2005 22:21:11 +0000 : Boris Mann Can someone roll a patch for this? Would be a good addition for 4.7 now that Atom is at 1.0. ------------------------------------------------------------------------ Fri, 29 Jul 2005 01:49:42 +0000 : Prometheus6 Attachment: http://drupal.org/files/issues/magpie_aggregator.zip (7.87 KB) A patch would require the Magpie include files and wholly restructures the way the feeds are parsed...the Magpie code would handle all the feeds, not just Atom. That said, the attached zip file has the necessary includes and a patch to CVS. ------------------------------------------------------------------------ Fri, 29 Jul 2005 03:36:59 +0000 : Steven Magpie RSS duplicates a lot of functionality that is already in Drupal. We decided a long time ago that we would not use it. Porting Atom parsing into the current aggregator can't be that hard. ------------------------------------------------------------------------ Mon, 01 Aug 2005 16:38:53 +0000 : Prometheus6 Attachment: http://drupal.org/files/issues/AGGREGATOR_ATOM_HEAD_0.txt (1.93 KB) Since I'm messing around with the aggregator module anyway... I developed this around Atom 0.3 feeds this weekend, but I don't see anything in Atom 1.0 that should break it. ------------------------------------------------------------------------ Tue, 02 Aug 2005 15:00:50 +0000 : Eaton +1 on that patch. Running it now on my test site and everything looks great. ------------------------------------------------------------------------ Tue, 02 Aug 2005 16:24:54 +0000 : Bèr Kessels a small issue, whe do not use if ($data) $items[$item][$tag] .= $data; please just use if ($data) { $items[$item][$tag] .= $data; } ------------------------------------------------------------------------ Wed, 03 Aug 2005 02:18:54 +0000 : Prometheus6 Attachment: http://drupal.org/files/issues/AGGREGATOR_ATOM_HEAD_1.txt (1.99 KB) Not a problem. Here's the corrections. ------------------------------------------------------------------------ Wed, 03 Aug 2005 16:14:14 +0000 : Dries If this is all it takes to parse Atom feeds (to some extend), I'm all for it. Code looks OK. Set to 'ready to be committed' after some testing.

1 0

[drupal-devel] [feature] Parse atom feeds
by Dries 03 Aug '05

03 Aug '05

Issue status update for http://drupal.org/node/13941 Post a follow up: http://drupal.org/project/comments/add/13941 Project: Drupal Version: cvs Component: aggregator.module Category: feature requests Priority: normal Assigned to: Prometheus6 Reported by: Capnj Updated by: Dries Status: patch (code needs review) If this is all it takes to parse Atom feeds (to some extend), I'm all for it. Code looks OK. Set to 'ready to be committed' after some testing. Dries Previous comments: ------------------------------------------------------------------------ Sun, 05 Dec 2004 23:26:00 +0000 : Capnj I've seen mention elsewhere on drupal.org but don't see a feature request, so here goes. The news aggregator is a great piece of Drupal as far as I'm concerned and I'd sure like to see it read all the sources out there, have the 'blog this' function, and also have a tool for browsers to generate a blog entry from a web page (like MT had). Is that a big enough request? LOL Thanks for all that everyone does here. Great stuff! gil ------------------------------------------------------------------------ Tue, 07 Dec 2004 17:38:31 +0000 : drumm RSS 2.0 feeds should work in 4.5.0 and earlier. ------------------------------------------------------------------------ Mon, 14 Feb 2005 16:04:32 +0000 : georgehotelling I've hacked Magpie [1] support into the Drupal aggregator, so it can support Atom. If you have a Drupal site and want the code, you can get it from http://george.hotelling.net/projects/magpie-aggregator-4.5.2.tgz [2] I'm not sure if I'm supposed to create a patch or what, but I needed this for ArborBlogs.com [3] and figured some other people would benefit from it. [1] http://magpierss.sourceforge.net/ [2] http://george.hotelling.net/projects/magpie-aggregator-4.5.2.tgz [3] http://www.arborblogs.com/ ------------------------------------------------------------------------ Tue, 15 Mar 2005 04:04:42 +0000 : Prometheus6 Attachment: http://drupal.org/files/issues/AGGREGATOR_ATOM_HEAD.txt (5.46 KB) Very nice. I hacked aggregator.module for 4.6 using your module as a guide...well, frankly by ripping out great chunks of code for my use. ------------------------------------------------------------------------ Thu, 28 Jul 2005 22:21:11 +0000 : Boris Mann Can someone roll a patch for this? Would be a good addition for 4.7 now that Atom is at 1.0. ------------------------------------------------------------------------ Fri, 29 Jul 2005 01:49:42 +0000 : Prometheus6 Attachment: http://drupal.org/files/issues/magpie_aggregator.zip (7.87 KB) A patch would require the Magpie include files and wholly restructures the way the feeds are parsed...the Magpie code would handle all the feeds, not just Atom. That said, the attached zip file has the necessary includes and a patch to CVS. ------------------------------------------------------------------------ Fri, 29 Jul 2005 03:36:59 +0000 : Steven Magpie RSS duplicates a lot of functionality that is already in Drupal. We decided a long time ago that we would not use it. Porting Atom parsing into the current aggregator can't be that hard. ------------------------------------------------------------------------ Mon, 01 Aug 2005 16:38:53 +0000 : Prometheus6 Attachment: http://drupal.org/files/issues/AGGREGATOR_ATOM_HEAD_0.txt (1.93 KB) Since I'm messing around with the aggregator module anyway... I developed this around Atom 0.3 feeds this weekend, but I don't see anything in Atom 1.0 that should break it. ------------------------------------------------------------------------ Tue, 02 Aug 2005 15:00:50 +0000 : Eaton +1 on that patch. Running it now on my test site and everything looks great. ------------------------------------------------------------------------ Tue, 02 Aug 2005 16:24:54 +0000 : Bèr Kessels a small issue, whe do not use if ($data) $items[$item][$tag] .= $data; please just use if ($data) { $items[$item][$tag] .= $data; } ------------------------------------------------------------------------ Wed, 03 Aug 2005 02:18:54 +0000 : Prometheus6 Attachment: http://drupal.org/files/issues/AGGREGATOR_ATOM_HEAD_1.txt (1.99 KB) Not a problem. Here's the corrections.

1 0

[drupal-devel] [bug] Statistic information about node reads is shown to unprivileged users
by Dries 03 Aug '05

03 Aug '05

Issue status update for http://drupal.org/node/22565 Post a follow up: http://drupal.org/project/comments/add/22565 Project: Drupal Version: cvs Component: statistics.module Category: bug reports Priority: normal Assigned to: Robin Monks Reported by: massabob Updated by: Dries Status: patch (ready to be committed) -1, the term "access statistics counter" doesn't tell me anything. The counters are for posts -- I think that should be reflected in the permission's name. Is this different from the 'Count content views' setting? Dries Previous comments: ------------------------------------------------------------------------ Wed, 11 May 2005 07:51:40 +0000 : massabob Information about '%count reads' in node's footer is shown to unprivileged users. I suggest that function statistics_link in statistics.module should be corrected in this way: // Original function statistics_link($type, $node = 0, $main = 0) { global $id; $links = array(); if ($type != 'comment' && variable_get('statistics_display_counter', 0)) { $statistics = statistics_get($node->nid); if ($statistics) { $links[] = format_plural($statistics['totalcount'], '1 read', '%count reads'); } } return $links; } // Fixed function statistics_link($type, $node = 0, $main = 0) { global $id; $links = array(); if ($type != 'comment' && variable_get('statistics_display_counter', 0) && user_access('display statistics')) { $statistics = statistics_get($node->nid); if ($statistics) { $links[] = format_plural($statistics['totalcount'], '1 read', '%count reads'); } } return $links; } The only change is in "&& user_access('display statistics')" on line 98. ------------------------------------------------------------------------ Fri, 27 May 2005 01:44:25 +0000 : RobRoy Should read user_access('access statistics') not user_access('display statistics'). ------------------------------------------------------------------------ Fri, 27 May 2005 11:19:36 +0000 : Robin Monks Attachment: http://drupal.org/files/issues/user.access.stats.patch (730 bytes) And here that is in patch form. Robin ------------------------------------------------------------------------ Wed, 01 Jun 2005 04:09:16 +0000 : Steven I'm not sure about this patch: often, read counts are shown directly on the site. But if the permission for viewing the counts is the same as the permission for accessing the administrator's detailed logs, then you wouldn't give that to everyone. There is already an option to choose whether counts are displayed. Perhaps we could change that to "No" "For priviledged users" "For everyone". In last case it acts like it is now, it the second case it requires "access statistics" permission. What do you think? ------------------------------------------------------------------------ Wed, 01 Jun 2005 14:13:54 +0000 : Robin Monks Sounds good to me. I'll try to code something up for this. Robin ------------------------------------------------------------------------ Thu, 09 Jun 2005 13:55:49 +0000 : Robin Monks Attachment: http://drupal.org/files/issues/authstats.patch (2.26 KB) Here is the patch. Uses a switch to choose between signed in users, all users, users with permissions or noone. Robin ------------------------------------------------------------------------ Thu, 09 Jun 2005 14:08:16 +0000 : Robin Monks I tested this patch with various settings on my local install and it worked fine. Robin ------------------------------------------------------------------------ Thu, 09 Jun 2005 16:30:25 +0000 : Bèr Kessels Is there a reason why you check for $user->uid? Whaen someone has "access statistics" set to anonymous users, your check for $user->uid will override taht settings. Not good IMO. <?php $group .= form_radios(t('Display counter values'), 'statistics_display_counter', variable_get('statistics_display_counter', 0), array('1' => t('For all users'), '2' => t('For authenticated users'), '3' => t('For priviledged users'), '0' => t('Disabled')), t('Display how many times given content has been viewed.')); ?> is very inconsistent. please use *only* the permissions page to set permissions, and do not create new permissions-alike settings in any configuration pages. I would say a simple check for user_access('access statistics') will do the trick ------------------------------------------------------------------------ Thu, 09 Jun 2005 16:32:53 +0000 : Bèr Kessels sorry, i meant to say user_access('access statistics counter'), not user_access('access statistics'). We already have "access statistics'" an additional "access statistics counter" for showing users the counter should work Ber ------------------------------------------------------------------------ Thu, 09 Jun 2005 16:49:48 +0000 : Robin Monks Attachment: http://drupal.org/files/issues/statistics.module (23.1 KB) OK, here is a patch to that end... Robin ------------------------------------------------------------------------ Thu, 09 Jun 2005 17:00:50 +0000 : Robin Monks Attachment: http://drupal.org/files/issues/authstats_0.patch (1 KB) Um, let's just pretend I didn't just upload the entire stats module. OK? OK! Robin ------------------------------------------------------------------------ Thu, 09 Jun 2005 17:05:59 +0000 : Robin Monks Attachment: http://drupal.org/files/issues/authstats_1.patch (1.06 KB) Hotfix. Robin ------------------------------------------------------------------------ Thu, 09 Jun 2005 17:11:23 +0000 : Robin Monks Attachment: http://drupal.org/files/issues/authstats_2.patch (1.11 KB) Hopefuly the final version. Thanks to chx and berkes for pulling it apart ;-) Robin ------------------------------------------------------------------------ Thu, 09 Jun 2005 17:21:38 +0000 : Bèr Kessels +1 for this patch. it adds functionality, but does not add clutter nor any config options. ------------------------------------------------------------------------ Fri, 10 Jun 2005 02:39:06 +0000 : frjo +1 I have implemented the patch authstats_2.patch on my site running Drupal 4.6.1 and it works well. ------------------------------------------------------------------------ Fri, 01 Jul 2005 08:10:22 +0000 : mfb +1 ------------------------------------------------------------------------ Fri, 01 Jul 2005 12:03:56 +0000 : Jose A Reyero +1 I tested the patch, works fine, and I'm always for "more options" ;-) ------------------------------------------------------------------------ Mon, 01 Aug 2005 21:17:48 +0000 : Junyor +1. Using this on my site now. ------------------------------------------------------------------------ Tue, 02 Aug 2005 21:53:15 +0000 : Robin Monks Attachment: http://drupal.org/files/issues/node_counter_permission.patch (2.97 KB) This patch revision removes the duplicate show counter option from the settings. Thanks UnConeD! Robin

1 0

[drupal-devel] [feature] insane state machine patch
by dikini 03 Aug '05

03 Aug '05

Issue status update for http://drupal.org/node/28113 Post a follow up: http://drupal.org/project/comments/add/28113 Project: Drupal Version: cvs Component: base system Category: feature requests Priority: normal Assigned to: dikini Reported by: dikini Updated by: dikini Status: patch (code needs review) Attachment: http://drupal.org/files/issues/insane_state_machine.patch (9.8 KB) This is a patch to introduce a simple (or insane if yo like) state machine. Why? After some irc discussions it came out that a lot of people would like flexible page workflow. This patch and the include file to follow offer a starting point to that. It doesn't change any of the standard apis, or the current workflow. Just enables the possibility of it. What changes? Introduce a new file - includes/machine.inc. It the most important part of it is the drupal_run() function. It implements the said machine. I've moved drupal_bootstrap and some relatives to this file, since it is easier to read the code when drupal_run and drupal_bootstrap are together. I've changed index.php, xml_rpc.php, update.php and cron.php to reflect the changes. I could've submitted a far bigger patch, but decided that the least intrusive, incremental approach is better. This is probably the reason, you would ask Q: Why do we want this thing? A: An approach like this opens several avenues to do more with drupal hooks. Let's take for example the node workflow. The execution of the different hooks is strictly ordered and immutable. There is no way for a module to insert a phase somewhere in that sequence. If, for example node is reworked to use this or similar approach the default node workflow will become mutable. This will offer a lot interesting opportunities, while not changing the current node behaviour and apis from its clients point of view. A second example I can see is easier implementation of the install and update system, since it will be able to hook into and extend drupal before the database is available, or into any other phase of the bootstrap process. The current code doesn't forbid branching. OK, this is long enough as it is, so I stop here dikini

2 3

[drupal-devel] Node listing question
by neil＠civicspacelabs.org 03 Aug '05

03 Aug '05

Can anyone think of a block (or potential block or other non-page thing) which lists nodes and is not associated with any page listing the same nodes? -Neil

4 3