August 2005 - Development - lists.drupal.org

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

01 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: Junyor -Status: patch (code needs review) +Status: patch (ready to be committed) +1. Using this on my site now. Junyor 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" ;-)

1 0

[drupal-devel] [bug] theme_add_style doesn't accommodate media type
by robertDouglass 01 Aug '05

01 Aug '05

Issue status update for http://drupal.org/node/27981 Post a follow up: http://drupal.org/project/comments/add/27981 Project: Drupal Version: cvs Component: theme system Category: bug reports Priority: normal Assigned to: robertDouglass Reported by: robertDouglass Updated by: robertDouglass Status: patch (code needs review) Attachment: http://drupal.org/files/issues/theme_add_style_media.txt (1.71 KB) we call theme_add_style with just a path even though it eventually triggers theme_stylesheet_import which accepts a parameter to specify media. The assumption that all stylesheets added with theme_add_style want to be media="all" is false. Patch adds the $media parameter and unifies variable naming between the two functions. robertDouglass

1 0

[drupal-devel] [feature] Put all throttle settings in the same place
by killes 01 Aug '05

01 Aug '05

Issue status update for http://drupal.org/node/27818 Post a follow up: http://drupal.org/project/comments/add/27818 Project: Drupal Version: cvs Component: throttle.module Category: feature requests Priority: normal Assigned to: drumm Reported by: drumm Updated by: killes(a)www.drop.org Status: patch (code needs review) -1 for adding yet another config page. teh throttle setting is fine where it is. killes(a)www.drop.org Previous comments: ------------------------------------------------------------------------ Sat, 30 Jul 2005 00:21:16 +0000 : drumm Attachment: http://drupal.org/files/issues/screenshot_12.png (37.86 KB) Screenshot 1/2. The modules admin page. ------------------------------------------------------------------------ Sat, 30 Jul 2005 00:24:10 +0000 : drumm Attachment: http://drupal.org/files/issues/screenshot_13.png (15.81 KB) Screenshot 2/2. The throttle modules page. ------------------------------------------------------------------------ Sat, 30 Jul 2005 00:29:32 +0000 : drumm Attachment: http://drupal.org/files/issues/throttle-modules.patch (9.73 KB) This patch needs http://drupal.org/node/27804. The throttle configuration is currently spread out on the modules page and the block configuration page. This patch moves the module throttling to a local task next to the throttle settings page. I have not worked on moving block throttling yet since I want to see what the reaction to this first part is. If this is comitted I plan to move the block throttle checkboxes and continue improving the modules page. With less interface elements the modules page can be made even simpler that is it now. ------------------------------------------------------------------------ Sat, 30 Jul 2005 19:48:47 +0000 : drumm forgot to label it as a patch ------------------------------------------------------------------------ Mon, 01 Aug 2005 20:21:27 +0000 : factoryjoe +1 for moving throttle/performance settings to it's own page/tab -1 for showing disabled modules; only list those that can be disabled Issues: * "turning on" throttling seems counter intuitive... like, all the modules should be checked as given priority... then you DESELECT in order to take it off the priority list. I guess the current UI is opposite of most conventions... where you start with everything enabled and then take things /off/ the list. * The list is not a scalable UI. If I have 60 modules (*cough cough*) I'll see the first 10-15 and ignore the rest. If you could sort by processing weight ("these modules suck up tonnes of memory! disable these first!") or by functionality, the list would be much more manageable. * I still think "throttle" is a terrible name. Like "taxonomy" people don't readily know what it means and avoid it like the plague. From a marketing perspective, this is bad news for Drupal since it may appears that Drupal is slow when it really just needs to have its *performance* settings tweaked.

1 0

[drupal-devel] Bug#316362: marked as done (security problem with drupal)
by owner＠bugs.debian.org 01 Aug '05

01 Aug '05

Your message dated Mon, 01 Aug 2005 22:26:03 +0200 with message-id <87hde91k10.fsf(a)ataraxia.int.hilluzination.de> and subject line A new version has been uploaded to sarge has caused the attached Bug report to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Debian bug tracking system administrator (administrator, Debian Bugs database) -------------------------------------- Received: (at submit) by bugs.debian.org; 30 Jun 2005 12:34:00 +0000 >From villain(a)ems.ru Thu Jun 30 05:34:00 2005 Return-path: <villain(a)ems.ru> Received: from router.ems.ru (relay-suttk.ems.ru) [62.165.34.129] by spohr.debian.org with esmtp (Exim 3.35 1 (Debian)) id 1DnyEy-0004zm-00; Thu, 30 Jun 2005 05:34:00 -0700 Received: from mail.ems.ru (localhost [127.0.0.1]) by mail.ems.ru (postfix) with ESMTP id 125C31AA68A for <submit(a)bugs.debian.org>; Thu, 30 Jun 2005 18:33:59 +0600 (YEKST) Received: from support.office.ems.chel.su (unknown [195.54.20.1]) by mail.ems.ru (postfix) with ESMTP for <submit(a)bugs.debian.org>; Thu, 30 Jun 2005 18:33:59 +0600 (YEKST) Received: by support.office.ems.chel.su (Postfix, from userid 1000) id C0EA22C56D; Thu, 30 Jun 2005 18:33:55 +0600 (YEKST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: Aleksey I Zavilohin <villain(a)ems.ru> To: Debian Bug Tracking System <submit(a)bugs.debian.org> Subject: security problem with drupal X-Mailer: reportbug 3.8 Date: Thu, 30 Jun 2005 18:33:55 +0600 Message-Id: <20050630123355.C0EA22C56D(a)support.office.ems.chel.su> X-Virus-Scanned: ClamAV using ClamSMTP Delivered-To: submit(a)bugs.debian.org X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2005_01_02 (1.212-2003-09-23-exp) on spohr.debian.org X-Spam-Status: No, hits=-8.0 required=4.0 tests=BAYES_00,HAS_PACKAGE autolearn=no version=2.60-bugs.debian.org_2005_01_02 X-Spam-Level: Package: drupal Version: 4.5.3-2 Severity: grave Justification: user security hole See http://drupal.org/files/sa-2005-002/advisory.txt ---------------------------------------------------------------------------- Drupal security advisory DRUPAL-SA-2005-002 ---------------------------------------------------------------------------- Advisory ID: DRUPAL-SA-2005-002 Date: 2005-jun-29 Security risk: highly critical Impact: system access Where: from remote Vulnerability: arbitrary PHP code execution ---------------------------------------------------------------------------- Description ----------- Kuba Zygmunt discovered a flaw in the input validation routines of Drupal's filter mechanism. An attacker could execute arbitrary PHP code on a target site when public comments or postings are allowed. Versions affected ----------------- Drupal 4.5.0, 4.5.1, 4.5.2, 4.5.3 Drupal 4.6.0, 4.6.1 Solution -------- Either disable public comments and postings, or upgrade to the latest Drupal version: - If you cannot upgrade immediately, you can secure your site by disabling public postings and comments. Log in as an administrator, go to "administer >> access control" and make sure that untrusted roles don't have the permissions to submit or edit content. - If you are running Drupal 4.5.x, then upgrade to Drupal 4.5.4. - If you are running Drupal 4.6.x, then upgrade to Drupal 4.6.2. Contact ------- The security contact for Drupal can be reached at security(a)drupal.org or using the form at http://drupal.org/contact. -- System Information: Debian Release: 3.1 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.8-2-686 Locale: LANG=ru_RU.KOI8-R, LC_CTYPE=ru_RU.KOI8-R (charmap=KOI8-R) Versions of packages drupal depends on: ii apache 1.3.33-6 versatile, high-performance HTTP s ii debconf 1.4.30.13 Debian configuration management sy ii makepasswd 1.10-2 Generate and encrypt passwords ii mysql-client-4.1 [mysql-clie 4.1.11a-4 mysql database client binaries ii php4-cli 4:4.3.10-15 command-line interpreter for the p ii php4-mysql 4:4.3.10-15 MySQL module for php4 ii postfix [mail-transport-agen 2.1.5-9 A high-performance mail transport ii wwwconfig-common 0.0.43 Debian web auto configuration -- debconf information excluded --------------------------------------- Received: (at 316362-done) by bugs.debian.org; 1 Aug 2005 20:26:18 +0000 >From bengen(a)debian.org Mon Aug 01 13:26:18 2005 Return-path: <bengen(a)debian.org> Received: from mail.kamp-dsl.de (dsl-mail.kamp.net) [195.62.99.42] by spohr.debian.org with smtp (Exim 3.36 1 (Debian)) id 1DzgrZ-0008GB-00; Mon, 01 Aug 2005 13:26:18 -0700 Received: (qmail 8820 invoked by uid 513); 1 Aug 2005 20:26:22 -0000 Received: from 213.146.117.234 by dsl-mail (envelope-from <bengen(a)debian.org>, uid 89) with qmail-scanner-1.24 (clamdscan: 0.80/609. spamassassin: 2.60. Clear:RC:1(213.146.117.234):SA:0(-1.6/5.0):. Processed in 1.366376 secs); 01 Aug 2005 20:26:22 -0000 Received: from hilluzination.de (HELO paranoia) (hillu%kamp-dsl.de(a)213.146.117.234) by dsl-mail.kamp.net with SMTP; 1 Aug 2005 20:26:20 -0000 Received: from [192.168.1.230] (helo=localhost.localdomain) by paranoia with esmtp (Exim 4.50) id 1DzgrL-00046d-Aj for 316362-done(a)bugs.debian.org; Mon, 01 Aug 2005 22:26:03 +0200 Received: from bengen by localhost.localdomain with local (Exim 4.52) id 1DzgrL-0002d3-Pl for 316362-done(a)bugs.debian.org; Mon, 01 Aug 2005 22:26:03 +0200 To: 316362-done(a)bugs.debian.org Subject: A new version has been uploaded to sarge Mail-Copies-To: nobody From: Hilko Bengen <bengen(a)debian.org> Date: Mon, 01 Aug 2005 22:26:03 +0200 Message-ID: <87hde91k10.fsf(a)ataraxia.int.hilluzination.de> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4 (Jumbo Shrimp, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Delivered-To: 316362-done(a)bugs.debian.org X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2005_01_02 (1.212-2003-09-23-exp) on spohr.debian.org X-Spam-Level: X-Spam-Status: No, hits=-3.0 required=4.0 tests=BAYES_00 autolearn=no version=2.60-bugs.debian.org_2005_01_02 I just noticed that this bug is still open, although a fixed package was uploaded weeks ago. Closing it.

1 0

[drupal-devel] [feature] Put all throttle settings in the same place
by factoryjoe 01 Aug '05

01 Aug '05

Issue status update for http://drupal.org/node/27818 Post a follow up: http://drupal.org/project/comments/add/27818 Project: Drupal Version: cvs Component: throttle.module Category: feature requests Priority: normal Assigned to: drumm Reported by: drumm Updated by: factoryjoe Status: patch (code needs review) +1 for moving throttle/performance settings to it's own page/tab -1 for showing disabled modules; only list those that can be disabled Issues: * "turning on" throttling seems counter intuitive... like, all the modules should be checked as given priority... then you DESELECT in order to take it off the priority list. I guess the current UI is opposite of most conventions... where you start with everything enabled and then take things /off/ the list. * The list is not a scalable UI. If I have 60 modules (*cough cough*) I'll see the first 10-15 and ignore the rest. If you could sort by processing weight ("these modules suck up tonnes of memory! disable these first!") or by functionality, the list would be much more manageable. * I still think "throttle" is a terrible name. Like "taxonomy" people don't readily know what it means and avoid it like the plague. From a marketing perspective, this is bad news for Drupal since it may appears that Drupal is slow when it really just needs to have its *performance* settings tweaked. factoryjoe Previous comments: ------------------------------------------------------------------------ Sat, 30 Jul 2005 00:21:16 +0000 : drumm Attachment: http://drupal.org/files/issues/screenshot_12.png (37.86 KB) Screenshot 1/2. The modules admin page. ------------------------------------------------------------------------ Sat, 30 Jul 2005 00:24:10 +0000 : drumm Attachment: http://drupal.org/files/issues/screenshot_13.png (15.81 KB) Screenshot 2/2. The throttle modules page. ------------------------------------------------------------------------ Sat, 30 Jul 2005 00:29:32 +0000 : drumm Attachment: http://drupal.org/files/issues/throttle-modules.patch (9.73 KB) This patch needs http://drupal.org/node/27804. The throttle configuration is currently spread out on the modules page and the block configuration page. This patch moves the module throttling to a local task next to the throttle settings page. I have not worked on moving block throttling yet since I want to see what the reaction to this first part is. If this is comitted I plan to move the block throttle checkboxes and continue improving the modules page. With less interface elements the modules page can be made even simpler that is it now. ------------------------------------------------------------------------ Sat, 30 Jul 2005 19:48:47 +0000 : drumm forgot to label it as a patch

1 0

[drupal-devel] [bug] Empty 'info' in custom block leads to errors
by tostinni 01 Aug '05

01 Aug '05

Issue status update for http://drupal.org/node/27713 Post a follow up: http://drupal.org/project/comments/add/27713 Project: Drupal -Version: 4.6.0 +Version: cvs Component: block.module Category: bug reports Priority: normal Assigned to: Anonymous Reported by: yelvington Updated by: tostinni -Status: active +Status: patch (ready to be committed) Attachment: http://drupal.org/files/issues/block_description.patch (1.39 KB) I think the unicity is to help admin find their blocks, but the bug is still there. In the CVS version, there's 2 little bugs corrected by this patch : - description field isn't marked as requiered - when the field isn't unique, an error is displayed, but the wrong text field is set as erronous. tostinni Previous comments: ------------------------------------------------------------------------ Thu, 28 Jul 2005 19:29:58 +0000 : yelvington When creating a custom block, the user is prompted for a "block description." The field is not marked as required. Since the description is likely to be redundant to the title, many admins may simply leave the description blank. In the database "boxes" table, the description is recorded in "info," which is defined as `info` varchar(128) NOT NULL default '', In addition, the column is indexed and marked UNIQUE. (Why??) As a result, omitting the description for more than one block causes an error like so: user error: Duplicate entry '' for key 3 query: INSERT INTO boxes (title, body, info, format) VALUES ('Test block', 'This is an empty block. ', '', 1) in /(path)/includes/database.mysql.inc on line 66.

1 0

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

01 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: Anonymous +Assigned to: Prometheus6 Reported by: Capnj Updated by: Prometheus6 -Status: active +Status: patch (code needs review) 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. 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.

1 0

[drupal-devel] [bug] apache and drupal both compressing pages
by moshe weitzman 01 Aug '05

01 Aug '05

Issue status update for http://drupal.org/node/13224 Post a follow up: http://drupal.org/project/comments/add/13224 Project: Drupal Version: cvs Component: base system Category: bug reports Priority: critical Assigned to: killes(a)www.drop.org Reported by: bertboerland(a)www.drop.org Updated by: moshe weitzman Status: patch (code needs review) In my opinion, this is a case of misplaced optimization. Very little CPU is required to gzip a document. Why else would Apache and PHP provide an option to do this *for every page*. PHP knows that all its pages will be dynamic yet it still offers this option. My recommendation is this feature entirely, and take the win in simplicity/code reduction. Furthermore, we won't have any more issues like this one, which has lingered unfixed for 9 months. Admins who want gzip will elect to do so in their php.ini or .htaccess. moshe weitzman Previous comments: ------------------------------------------------------------------------ Sat, 20 Nov 2004 16:22:55 +0000 : bertboerland(a)www.drop.org hi this weekend I went ahead and upgraded drupal from 4.4 to 4.5 on a machine, I dint have time/priority (in Dutch these words are almost the same :-) sooner. The core went fine and as usual lots of unpacking, configuring for all the modules I want to experiment with. After some time I tried to access the site in a -just-to-be-sure- moment from windows machine with an IE browser without being logged in. I found some strange behavior. Sometimes IE wanted to download the file, sometimes it showed the file (being a binary) and sometimes I got a valid page. I never got this from my firefox on both windows and Linux while being logged in. Later I could reproduce this on a firefox browser without being logged in. After some time / thinking I think I found out that both apache (my webserver) and drupal were compressing (gzipping) the page resulting in a browser that was able to uncompress the page once. But if it was a cached page and drupal was zipping this and Apache as well, the browser was just displaying a gzipped page. I have a rather old setup with an ancient version of apache but does this sound possible? Since I am hosting (some) other content outside the drupal dir, I would like to keep apache gzipping pages so is there an option to stop drupal from compressing pages? ------------------------------------------------------------------------ Sat, 20 Nov 2004 16:32:16 +0000 : killes(a)www.drop.org Which method use your Apache to gzip the pages? Which version is it? I find it strange that we get this report only several weeks after the release. I suspect that your particualr set up is borken. ------------------------------------------------------------------------ Sat, 20 Nov 2004 16:45:23 +0000 : bertboerland(a)www.drop.org The reason I waited so long was that I wanted others to find out this :-) Mind you, I *think* it is the fact that they are both compressing the cached pages. You might want to try it out for yourself by going to http://willy.boerland.com/myblog and in case a there is a cached page you will end up by downloading a binary that once renamed to a gz and unpacked, will give you the html file. drupal 4.5 apache: 1.3.26 (with *all* security patches) php: 4.2.3 Content-Encoding: gzip And yes, since I quess 100+ sites are already at 4.5 I think it is related to my setup. However, I understand correctly there i no way of having drupal stop sending out compressed pages? There is no configuration option? ------------------------------------------------------------------------ Sat, 20 Nov 2004 17:06:05 +0000 : killes(a)www.drop.org Yes, I get funny garbage, too. The apache version you run is the one Debian provides. It is still used very often, but still nobody but you seems to experience the problem, so I still think that somehow your setup is broken. Apache should recognize that the page is already gzipped. Do you use mod_gzip or libz? ------------------------------------------------------------------------ Sat, 20 Nov 2004 17:57:14 +0000 : bertboerland(a)www.drop.org Since this one is more or less critical for me but not for the RotW, re-setting priority to "nomal". I am using zlib btw. Did you try to save the file and unzip it? And I am correct that there is no option to disable cached paged from being zipped? ------------------------------------------------------------------------ Sat, 20 Nov 2004 18:30:23 +0000 : bertboerland(a)www.drop.org I think I "solved" this for me by changing the bootstrap.inc setting this to postponed, if no-one else experiences this problem within 3 weeks I will close this issue. ------------------------------------------------------------------------ Sat, 20 Nov 2004 18:31:19 +0000 : killes(a)www.drop.org I tried to download it now, but you must have changed something, the page renders fine. You are right, there is no option to disable gzipped cache. I'd really like to discover the reason for this problem. Normally, zlib should check for gzipped content and do not gzip it again. Drupal sends the appropriate header. ------------------------------------------------------------------------ Sat, 20 Nov 2004 18:32:25 +0000 : killes(a)www.drop.org Locking could have prevented this. ;) ------------------------------------------------------------------------ Sun, 21 Nov 2004 12:36:23 +0000 : axel(a)drupal.ru > I found some strange behavior. Sometimes IE wanted to download the file, sometimes it showed the file (being a binary) and sometimes I got a valid page. Sometimes I got same thing in Mozilla Firefox with differrent sites (not sure, but not only with Drupal) when I work trough my local proxies (I use chain of two proxies on my Debian box - one for banner deleting (privoxy) and second for offline page caching (wwwoffle)). I don't dig to details of such behaviour, but simply switch off proxies and reload browser's page help to solve problem - then I again switch on proxies and page loaded ok. May be you also access site through proxy? Then you need to check this proxy settings, I think. ------------------------------------------------------------------------ Sun, 21 Nov 2004 21:13:26 +0000 : bertboerland(a)www.drop.org Axel, no it was not related to proxys or even the browser. It was related to cached pages being zipped by drupal and sent to apache that was ziping the page as well, resulting in a zipped zipped page for the client that only once unzipped the page and hence displayed a binary ------------------------------------------------------------------------ Tue, 21 Dec 2004 17:10:12 +0000 : bertboerland(a)www.drop.org It seems like I was not the only one [1]. There is not enough information about the others setup (/please post here!/) to find a generic cause, but it is sure that some setups will cause zipped pages to be zipped. [1] http://drupal.org/node/14569 ------------------------------------------------------------------------ Thu, 03 Feb 2005 15:03:17 +0000 : leafish_dylan Has anybody found a better way to fix this problem? Disabling the storage of compressed cache pages in bootstrap.inc works, but it's ugly. Is an uncompressed cache likely to take up a lot of space in the database? If not, perhaps a global "gzip/zlib compression" option for Drupal would be simpler. ------------------------------------------------------------------------ Sat, 05 Feb 2005 14:40:16 +0000 : Anonymous As author of the gzipped cache patch I'd really appreciate if the people who experience this problem could supply detailed(!) info on their setup and the headers sent both by the browser and the server. I'd like to fix the problem (if there is one on Drupal's side) or at least document correct server settings if the problem is there. ------------------------------------------------------------------------ Sat, 05 Feb 2005 16:54:42 +0000 : bertboerland(a)www.drop.org Here some info, please ask if you need more: apache 1.3.26 mmcache (version unknown) drupal 4.5.1 Note: I didnt post (and thought abaout!) the MMcache between drupal and apache. The configuration of mmcache is extension="mmcache.so" mmcache.shm_size="16" mmcache.cache_dir="/tmp/mmcache" mmcache.enable="1" mmcache.optimizer="1" mmcache.check_mtime="1" mmcache.debug="0" mmcache.filter="" mmcache.shm_max="0" mmcache.shm_ttl="0" mmcache.shm_prune_period="0" mmcache.shm_only="0" mmcache.compress="1" headers: http://willy.boerland.com/myblog/ GET /myblog/ HTTP/1.1 Host: willy.boerland.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0 Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5 Accept-Language: en-us,en;q=0.5 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive Cookie: PHPSESSID=307f07c169e3bbcbe92d150026c97583 HTTP/1.x 200 OK Date: Sat, 05 Feb 2005 16:45:49 GMT Server: Apache-AdvancedExtranetServer/1.3.26 X-Powered-By: PHP/4.2.3 Content-Encoding: gzip Keep-Alive: timeout=15, max=100 Connection: Keep-Alive Transfer-Encoding: chunked Content-Type: text/html; charset=utf-8 ---------------------------------------------------------- ------------------------------------------------------------------------ Mon, 21 Feb 2005 10:53:02 +0000 : coma I have exactly the same problem my setup it's currently apache 2.0.52, php 4.3.10 and drupal 4.5.2. The relevant info it's: from apache: <Location /> # Insert filter SetOutputFilter DEFLATE # Netscape 4.x has some problems... BrowserMatch ^Mozilla/4 gzip-only-text/html # Netscape 4.06-4.08 have some more problems BrowserMatch ^Mozilla/4\.0[678] no-gzip # MSIE masquerades as Netscape, but it is fine BrowserMatch \bMSIE !no-gzip !gzip-only-text/html # Don't compress images SetEnvIfNoCase Request_URI \ \.(?:gif|jpe?g|png)$ no-gzip dont-vary # Make sure proxies don't deliver the wrong content Header append Vary User-Agent env=!dont-vary </Location> In php.ini: zlib.output_compression = On And I can assure you that my problem was that last element, changing zlib.output_compression to off solved the problem, and the output of all php scripts (not only drupal) it's compressed by either drupal or apache. You can test this things with wget: wget --header "Accept-Encoding: gzip,deflate" http://localhost/ The file wget drops should be a gzippped html, if you do a zcat and get a plain html it's all good, if you get another gzipped file it has been double compressed. ------------------------------------------------------------------------ Sat, 02 Apr 2005 19:38:42 +0000 : moshe weitzman i too am seeing strange behavior here. specifically, php is simply dieing after printing out the $cache->data in drupal_page_header(). truly, i don't think drupal should be storing gzipped cache, nor do i think it should perform gzip at all. these are better handled at php or apache layers. ------------------------------------------------------------------------ Sat, 23 Apr 2005 14:06:14 +0000 : mjr Apparently i am observing a new variant of that problem in one of the subsites of my 4.6 test installation: after enebaling cacheing, lynx, w3m and the gecko based browsers display garbage. lynx tells me it wants to load a file named index.html.gz. wget http://beate/drupal46/ on that site gives a readable html page. w3m -dump_head tells me: Received cookie: PHPSESSID=a6916d57d08727ab8ed945ddac4ecf2c HTTP/1.1 200 OK Date: Sat, 23 Apr 2005 13:56:19 GMT Server: Apache/2.0.53 (Debian GNU/Linux) PHP/4.3.10-10 mod_ssl/2.0.53 OpenSSL/0.9.7e mod_perl/1.999.20 Perl/v5.8.4 X-Powered-By: PHP/4.3.10-10 Set-Cookie: PHPSESSID=a6916d57d08727ab8ed945ddac4ecf2c; expires=Mon, 16 May 2005 17:29:39 GMT; path=/ Expires: Sun, 19 Nov 1978 05:00:00 GMT Last-Modified: Sat, 23 Apr 2005 13:56:19 GMT Cache-Control: no-store, no-cache, must-revalidate Cache-Control: post-check=0, pre-check=0 Pragma: no-cache Content-Encoding: gzip Vary: Accept-Encoding Connection: close Content-Type: text/html; charset=utf-8 Apparently, the site sends uncompressed pages but tells the browser it is compressed. BTW, links2 and dillo do disply the page but will not allow me to log in and disable cacheing. Any clues? Thanks Michael ------------------------------------------------------------------------ Sat, 23 Apr 2005 14:08:42 +0000 : mjr Perhaps I should mention that zlib.output_compression = Off in my php.ini ------------------------------------------------------------------------ Sat, 23 Apr 2005 18:43:30 +0000 : bertboerland(a)www.drop.org /Apparently i am observing a new variant of that problem / Please open a new bug report, since your problem is likely unrelated to this problem, open an new problem and you might want to use a link to this problem, but dont use this problem for other than descibed. ------------------------------------------------------------------------ Sat, 04 Jun 2005 23:53:22 +0000 : mjr no, it is not unrelated. After some investigation, i found out that the garbage is being stored in drupals cache. This has been reported in this thread. My present workaround is to completly disable drupals caching (and to manually delete the compressed pages from the database.) Whats the use of letting drupal compress pages and store these int its cache table? Just saving a few cycles of CPU time? On the cost of letting the web server and its client decide wether to transfer compressed or uncompressed data - they have the protocol to do that, drupal has not. Michael ------------------------------------------------------------------------ Mon, 06 Jun 2005 16:48:30 +0000 : killes(a)www.drop.org We save cpu cycles and storage space. Apache only needs to check the Encoding header which will be easy. I do not know why zlib output compression doesn't check those headers for some (or all?) people. ------------------------------------------------------------------------ Fri, 10 Jun 2005 23:32:40 +0000 : bluec I have the same problem with Drupal 4.6.1: If the site delivers a cached page it is gziped twice and the result is garbage in my browser window. I tried two differnet browsers: Firefox and Opera and it's the same problem with both of them. I recorded the HTTP headers: - Cache turned on - zlib-compression turned on - Result: Garbage http://kim.sshtun.v63.org:22003/index.html GET /index.html HTTP/1.1 Host: kim.sshtun.v63.org:22003 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4 Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5 Accept-Language: de-de,en;q=0.5 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive Referer: http://kim.sshtun.v63.org:22003/fachschaft/ Cookie: PHPSESSID=6ddbf3d5a32d-CHANGED-BY-CHRIS HTTP/1.x 200 OK Date: Fri, 10 Jun 2005 23:16:08 GMT Server: Apache/2.0.54 (Gentoo/Linux) mod_ssl/2.0.54 OpenSSL/0.9.7e PHP/5.0.4 X-Powered-By: PHP/5.0.4 Expires: Mon, 26 Jul 1997 05:00:00 GMT Last-Modified: Fri, 10 Jun 2005 23:11:59 GMT Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0 Pragma: no-cache Set-Cookie: PHPSESSID=6ddbf3d5a32d20-CHANGED-BY-CHRIS; expires=Mon, 04 Jul 2005 02:49:28 GMT; path=/ Etag: "03cff5fcc105e72dfc2671d3ffdb285c" Content-Encoding: gzip Content-Length: 5024 Keep-Alive: timeout=15, max=95 Connection: Keep-Alive Content-Type: text/html; charset=utf-8 Now I turned off compression by setting in my .htaccess php_flag zlib.output_compression On and the result is OK: http://kim.sshtun.v63.org:22003/index.html GET /index.html HTTP/1.1 Host: kim.sshtun.v63.org:22003 User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4 Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5 Accept-Language: de-de,en;q=0.5 Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive Referer: http://kim.sshtun.v63.org:22003/index.html Cookie: PHPSESSID=6ddbf3d5a32d20-CHANGED-BY-CHRIS HTTP/1.x 200 OK Date: Fri, 10 Jun 2005 23:17:08 GMT Server: Apache/2.0.54 (Gentoo/Linux) mod_ssl/2.0.54 OpenSSL/0.9.7e PHP/5.0.4 X-Powered-By: PHP/5.0.4 Expires: Mon, 26 Jul 1997 05:00:00 GMT Last-Modified: Fri, 10 Jun 2005 23:11:59 GMT Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0 Pragma: no-cache Set-Cookie: PHPSESSID=6ddbf3d5a32d208-CHANGED-BY-CHRIS; expires=Mon, 04 Jul 2005 02:50:28 GMT; path=/ Etag: "03cff5fcc105e72dfc2671d3ffdb285c" Content-Encoding: gzip Vary: Accept-Encoding Content-Length: 5054 Keep-Alive: timeout=15, max=100 Connection: Keep-Alive Content-Type: text/html; charset=utf-8 Turning off the cache is a solution as well. As soon as cache and zlib are operating the result is garbage. If you need any other information just let me know. I can turn on compression at any time and test other solutions. Chris ------------------------------------------------------------------------ Mon, 27 Jun 2005 18:10:12 +0000 : aries The same. Interesting, only one page doing this, all others are not. -- Aries http://aries.mindworks.hu ------------------------------------------------------------------------ Thu, 07 Jul 2005 14:46:34 +0000 : fago quite strange. i never had problems with this, then i upgraded from 4.6.1 to drupal 4.6.2... now i must turn off the cache, or i've the troubles mentioned here... (i haven't touched the apache or php config in the meanwhile) ------------------------------------------------------------------------ Thu, 14 Jul 2005 09:47:32 +0000 : bertboerland(a)www.drop.org yet another one [2], closed than one, raised importance here. [2] http://drupal.org/node/25326 ------------------------------------------------------------------------ Sat, 16 Jul 2005 19:52:26 +0000 : bertboerland(a)www.drop.org killes sigested that is want apache that compressed the page but drupal and php was the first one. after some testing, i found out he was correct! to solve this 1) either comment out the gzip lines in bootstrap.inc 2) put /etc/php.ini "zlib.output_compression = On" to OFF (real) Fix needed. Drupal should look if the page was zipped in the first place.... ------------------------------------------------------------------------ Fri, 29 Jul 2005 12:17:46 +0000 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/gzip.patch (2.45 KB) Here's a patch that needs some testing. ------------------------------------------------------------------------ Fri, 29 Jul 2005 13:18:51 +0000 : Dries Why do we set $do_cache to TRUE in the nested if's? $do_cache is already set to TRUE higher up so we're just overwriting TRUE with TRUE? Also, can we rename $do_cache to $cache? That is more Drupal-ish. Does that solve all apache-Drupal-caching problems or only some? I vaguely remember we agreed to add a setting, because that was perceived the only True Solution. ------------------------------------------------------------------------ Fri, 29 Jul 2005 18:22:04 +0000 : killes(a)www.drop.org Attachment: http://drupal.org/files/issues/gzip_0.patch (2.46 KB) I've updated the patch. The patch is intended to cure all the problems we had. It needs testing, though. I don't recall to agreeing that a setting would be needed. Just for the record: Steven measured the ratio of serving gzipped cached pages to re-unzipped pages on drupal.org to be about 5.1:1. That is from 6 page requests which we serve from the cache only one needs the cache to be unzipped. This is probably due to crawlers who only speak http 1.0. ------------------------------------------------------------------------ Sat, 30 Jul 2005 14:33:42 +0000 : bertboerland(a)www.drop.org people who expierenced this problem, please try the patch of killes and report here if successful or not. i will patch as well

1 0

[drupal-devel] [bug] cvs node.module incorrectly assumes 404 when access denied
by willmoy 01 Aug '05

01 Aug '05

Issue status update for http://drupal.org/node/27873 Post a follow up: http://drupal.org/project/comments/add/27873 Project: Drupal Version: cvs Component: node.module Category: bug reports Priority: normal Assigned to: willmoy Reported by: willmoy Updated by: willmoy Status: patch (code needs review) Later cousin of http://drupal.org/node/27864 for 4.6.2 To reproduce: - Take a page which is denied to anonymous users by node_privacy_byrole - Go to it as an anonymous user - Receive 404 error cvs shares the same code for both the view and edit ops, so a slightly larger patch willmoy

2 3

[drupal-devel] RFC: drupalversions.module
by eric Farris 01 Aug '05

01 Aug '05

A common request in Drupalspace is a way to keep track of which version of Drupal is running on a Drupal site. While the CHANGELOG.txt file will show the current version, that's not entirely accurate, as pieces of the code could be patched, contributed modules could be installed, or the site could be some version of Drupal HEAD (where the changelog version is moot). What is needed is a single, agreed-upon method of discovering and reporting the versions of the various code used in a Drupal installation. What I propose is a drupalversions.module to handle this task. The features of such a module should be: * discovery of the CVS $Id$ tags of every .module, .inc, .theme, .css .xtmpl, etc. storing of these version numbers * comparison of these versions to official Drupal releases, and reporting of variations from the standard release numbers reporting of all non-core files and their version numbers * a good report that could be requested by drupal-support to assist in bug tracking and problem solving. Advanced features could be: * versions of contributed modules that correspond to official Drupal core releases. For example, the author of image.module could specify that version 1.220 is the first version to be used with Drupal 4.6.0, and that it is compatible with 4.6.1 and 4.6.2, but image.module 1.224 should be used with Drupal 4.6.3, and 1.230 is for Drupal HEAD only. So the drupalversions schema would have to store the filenames of all files in the Drupal core and the version numbers of the official releases. This would have to be easily extendable/accessible by contributed modules through a hook or api. We should support problems like this (examples only): * "node.module 1.410.2.6 is the official version for Drupal 4.6.0." * "For Drupal 4.6.2, Image.module should be 1.224 or higher." * "weblink.module 1.30 requires common.inc version 1.401.2.3 or higher." * This installation is a 4.6.2 version of Drupal, except that the node.module and search.module appear to be newer, and the following contrib modules are installed..." What I'm not addressing is the question of patches. It would be simple enough, I think, to store MD5 hashes from the 'official' module and have hook_cron periodically compute the hashes and compare them with the db, which would then appear on the admin report which files weren't in sync with their official versions. How would all of this fit in to the install system? I am in no position to start contributing code to this at present, but I plan on doing so if there is such a need. I still don't know what the hook would look like or what the schema would be. So... what do you think, sirs? -- e one inch frame: http://eafarris.al.umces.edu/

10 12