February 2005 - Development - lists.drupal.org

[drupal-devel] [bug] Internationalization: Create user-defined string variable whenever possible
by killes 19 Feb '05

19 Feb '05

Project: Drupal -Version: 4.5.2 +Version: cvs Component: base system -Category: tasks +Category: bug reports Priority: normal -Assigned to: Anonymous +Assigned to: killes(a)www.drop.org Reported by: Carl McDade Updated by: killes(a)www.drop.org -Status: active +Status: patch Attachment: http://drupal.org/files/issues/message-access.patch (2.99 KB) The original description is a bit unclear, but the underlying concern seems to be that the error messages are not specific to the situation they occur in. I share this concern. The attached patch removes the function message_access() (which hails from 2001) and replaces the six calls to it by hopefully better chosen strings. Since I do not use blogapi.module I welcome suggestions for better phrases. Since this is actually a usability bug fix i hope this can get into 4.6. killes(a)www.drop.org Previous comments: ------------------------------------------------------------------------ February 19, 2005 - 18:50 : Carl McDade Attachment: http://drupal.org/files/issues/common_11.patch (503 bytes) There should be an effort to externalize all english text into default variables. It makes a great step towards true internatiolization. Does not cost anything in terms of performance or matainance. What it does do is make the code that uses hard coded strings open and more resuable. It adds the flexibility in phrasology that is necessary in internationalizing Drupal. It creates more usability in that better text instructions can be delivered to the user based on the situation of the process. I have made this slight change in my install which allows me to give a descriptive message based on the url tried. This can be done in both english and swedish without me having to use gettext and the like. <?php --- common_1.inc 2005-02-19 17:33:21.451910400 +0100 +++ common_2.inc 2005-02-19 17:34:40.876116800 +0100 @@ -427,8 +427,8 @@ function object2array($object) { * Always consider whether to use drupal_access_denied() instead to return a * proper (and customizable) 403 error. */ -function message_access() { - return t('You are not authorized to access this page.'); +function message_access($message = 'You are not authorized to access this page.') { + return t($message); } *Warning*: Unterminated comment starting line 13 in */home/www/drupal.org/modules/codefilter/codefilter.module* on line *28* -- View: http://drupal.org/node/17592 Edit: http://drupal.org/project/comments/add/17592

1 0

[drupal-devel] [bug] htaccess patch
by Uwe Hermann 19 Feb '05

19 Feb '05

Project: Drupal Version: cvs Component: base system Category: bug reports Priority: normal Assigned to: Anonymous Reported by: Uwe Hermann Updated by: Uwe Hermann Status: patch Attachment: http://drupal.org/files/issues/htaccess_1.patch (458 bytes) Hi, >From the CVS log: 2005-01-28 17:30 dries * .htaccess (1.60): - Oops. 2005-01-28 16:47 dries * .htaccess (1.59), CHANGELOG.txt (1.62), database/database.mysql (1.168), database/updates.inc (1.90), modules/forum.module (1.226), modules/taxonomy.module (1.171): - Patch #10425 by ccourtne and walkah: added admin screens to maintain forums instead of forcing the user to add a taxonomy. The patch to .htaccess was: Index: .htaccess =================================================================== RCS file: /cvs/drupal/drupal/.htaccess,v retrieving revision 1.58 retrieving revision 1.59 diff -u -r1.58 -r1.59 --- .htaccess 9 Oct 2004 20:41:49 -0000 1.58 +++ .htaccess 28 Jan 2005 15:47:03 -0000 1.59 @@ -16,10 +16,11 @@ ErrorDocument 404 /index.php # Set the default handler to index.php: -DirectoryIndex index.php +#DirectoryIndex index.php # Overload PHP variables: -<IfModule mod_php4.c> +#<IfModule mod_php4.c> +<IfModule sapi_apache2.c> # If you are using Apache 2, you have to use <IfModule sapi_apache2.c> # instead of <IfModule mod_php4.c>. php_value register_globals 0 @@ -64,4 +65,4 @@ RewriteRule ^(.*)$ index.php?q=$1 [L,QSA] </IfModule> -# $Id: .htaccess,v 1.58 2004/10/09 20:41:49 dries Exp $ +# $Id: .htaccess,v 1.59 2005/01/28 15:47:03 dries Exp $ Dries, you reverted the IfModule stuff, but left in the "#DirectoryIndex index.php" (it's commented out, which it wasn't before). Is this by design or an oversight? I guess the latter, so one-line patch attached. HTH, Uwe. Uwe Hermann -- View: http://drupal.org/node/16621 Edit: http://drupal.org/project/comments/add/16621

2 1

[drupal-devel] [bug] Clicking on Home after login brings up browser-cached non-logged-in version of home page
by killes 19 Feb '05

19 Feb '05

Project: Drupal Version: cvs Component: user system Category: bug reports Priority: critical Assigned to: mathias Reported by: christianlong(a)christianlong.com Updated by: killes(a)www.drop.org Status: patch This patch only affects users of mod_expires and harms nobody else. +1 killes(a)www.drop.org Previous comments: ------------------------------------------------------------------------ February 16, 2004 - 21:44 : christianlong(a)christianlong.com Attachment: http://drupal.org/files/issues/f_040214_01.txt (6.33 KB) This bug has been discussed before, but not resolved. http://drupal.org/node/view/1740 http://drupal.org/node/view/5686 One suggestion was to change the browser settings. That means I have to tell all my users to change their browser cache settings. Not a great way to run a site. Instead, the login should just work with default browser settings. Currently, login does not work, as described below. I log in to my drupal site, feingold.christianlong.com, and the logged-in home page appears, with my user name. OK. The address bar shows http://feingold.christianlong.com/node?PHPSESSID=867c4e2d57d290a3f59e138524… In the site menu, the "Home" link links to http://feingold.christianlong.com/ Here's the problem: when I click on the "Home" link, the browser takes me to the un-logged-in version of http://feingold.christianlong.com/, which was cached when I was not logged in. When I hit refresh, I do get the logged-in version of the page. So, to restate Start at home page of site, not logged in Log in - this works, and brings up a logged-in version of the page Click "Home" - this is where the problem is. I get the cached version of the home page (from when I was not logged in) Refresh browser - now I see the correct, logged-in version of the home page. It looks like I am logging in OK, but that Drupal is not telling my browser that there is a new version of the home page that it needs to check for Maybe the original (non-logged-in) version of the page is not marked for no-cache, and so when I click on the "Home" link, I get the cached (non-logged-in) version Browsers: MSIE 6 (happens a lot) and Firebird (happens sometimes). Also happens with christianlong.com Attached, find an annotated record of the HTTP header traffic. Thanks Christian ------------------------------------------------------------------------ February 16, 2004 - 21:48 : christianlong(a)christianlong.com Forum discussion is here http://drupal.org/node/view/5669 ------------------------------------------------------------------------ March 4, 2004 - 18:49 : moshe weitzman I am seing this same behavior at http://www.nshp.org [1]. To see for yourself, login using the box on the home page while using IE (Firefox doesn't have a problem). user: mwtest8 pass: testpass Here is the php config of the server [2]. Note that IE is set to "Check for newer pages: automatically" in Options -> Temporary Internet Files -> Settings Thoughts on how to resolve this are welcome. [1] http://www.nshp.org/phpinfo.php [2] http://www.nshp.org/phpinfo.php ------------------------------------------------------------------------ June 16, 2004 - 03:38 : duztin I had this problem, fix the date on your pc, mine was a month ahead and my cookies were expiring too soon. ------------------------------------------------------------------------ July 27, 2004 - 21:18 : killes(a)www.drop.org Setting to cvs. Is the fix proposed by duztin a real fix? if not: what else could we do? ------------------------------------------------------------------------ October 16, 2004 - 22:45 : mathias Attachment: http://drupal.org/files/issues/browser_caching.patch (644 bytes) I'm moving this to critical because in some cases this bug causes the hidden $edit['destination'] value of the login form to be set to 'logout', and to the user it appears they can't login since they are immediately logged out again. Very frustrating. The other side effect of this browser caching bug are, as stated above, the authenticated user will receive stale pages and if you have the login block enabled it will look as though they're were unexplicably logged out. It all depends on your browser and its settings, but to attempt to reproduce: 1. Login to your site. 2. Next, Click the homepage link. If you are served a stale copy of the page, you've hit the bug. This seems to happen more with IE and Safari than Firefox. A potential patch is to have Drupal issue the following header: header('Cache-Control: no-store, no-cache, must-revalidate'); It works, but I don't know the implications this has on other Drupal components such as RSS conditional GETS and gzip page serving. ------------------------------------------------------------------------ October 21, 2004 - 19:30 : mathias Attachment: http://drupal.org/files/issues/browser_caching_0.patch (593 bytes) Thanks to Ethereal [3] and LiveHTTPHeaders [4], I was able to trace this problem to the Cache-Control header being sent by Mac OS X server. On this OS, mod_expires [5] is enabled by default for Apache which sets the Cache-Control time to 60 seconds for dynamically rendered pages. The implications of this action are that once you login, re-visiting any page on the site will result in stale, locally-cached versions if you viewed that page within 60 seconds of logging in. Since you weren't logged in on those pages, the system will have appeared to logged you out. It will keep doing this unless you wait 60 seconds to login. Thus, users perceive this as a failure to successfully log in. This new patch doesn't tweak bootstrap.inc. Instead it uses .htaccess to test if mod_expires is enabled and resets the caching time to 1 second for dynamically rendered content. The benefit of this approach is that it doesn't interfere with other types of caching that may be in place for images, pdf files, etc. # Overload mod_expires variables. <IfModule mod_expires.c> # Reduce the time dynamically generated HTML pages are cache-able. ExpiresDefault A1 </IfModule> Down the road it may also be wise to consider sending our own caching headers to maintain control of our caching environment. I reviewed the following pieces of software, all of which intentionally disable caching by the client browser or proxy caches. I just grabbed the ones I thought were most popular. Plone (Cache-Control parameter is configurable) Wordpress (except for RSS feeds) eZpublish Mambo phpBB And if you're so inclined, here's the relevent code snippets [6] for each piece of software. [3] http://www.ethereal.com/ [4] http://livehttpheaders.mozdev.org/ [5] http://httpd.apache.org/docs/mod/mod_expires.html [6] http://asitis.org/tmp/cms_cache_review.txt ------------------------------------------------------------------------ October 21, 2004 - 19:39 : moshe weitzman I'v seen this bug on drupal.org, so this impacts more than OSX server ... Looks like a nice clean patch to me. ------------------------------------------------------------------------ October 26, 2004 - 17:21 : jvandyk +1 from me. This reduces confusion among end users while retaining caching ability for other mime types. ------------------------------------------------------------------------ October 27, 2004 - 09:05 : wazdog Does this end up having any effect on the RSS conditional GETS? If not, then +1 from me. (The WordPress code does check for RSS, so I'm thinking this may set them to expire too?) ------------------------------------------------------------------------ October 28, 2004 - 02:58 : jvandyk Attachment: http://drupal.org/files/issues/htaccess_0.patch (792 bytes) Regarding the concern about RSS caching: this patch is identical to the previous one except instead of targetting the default we target the text/html MIME type. <IfModule mod_expires.c> # Reduce the time dynamically generated HTML pages are cache-able. ExpiresByType text/html A1 </IfModule> This means that RSS feeds, which are MIME type text/xml, are not affected. ------------------------------------------------------------------------ February 11, 2005 - 02:47 : moshe weitzman i think this is a small, worthwhile patch. this bug plagues drupal.org as well. ------------------------------------------------------------------------ February 11, 2005 - 14:45 : Junyor @jvandyk: Is it just me or is there some junk before the meat of that patch? Better cache header handling would be a welcome addition here[1], but I'm not sure if the suggested patch will solve the problem efficiently. Isn't this change saying that all pages must always be redownloaded if mod_expires is enabled? Won't that cause unnecessary bandwidth and performance overhead? [1] I'm constantly seeing stale pages throughout all authenticated pages with Opera. ------------------------------------------------------------------------ February 11, 2005 - 15:42 : moshe weitzman "Isn't this change saying that all pages must always be redownloaded if mod_expires is enabled?" Correct. And that is desired behavior. A dynamic application like ours has no choice but to redownload every page (excluding RSS feeds). -- View: http://drupal.org/node/5900 Edit: http://drupal.org/project/comments/add/5900

1 0

[drupal-devel] [bug] PHP session settings to relocate to support multiple sites
by tangent 19 Feb '05

19 Feb '05

Project: Drupal Version: cvs Component: base system Category: bug reports Priority: normal Assigned to: Anonymous Reported by: tangent Updated by: tangent Status: patch Attachment: http://drupal.org/files/issues/settings-session.patch (1.71 KB) As discussed in this issue [1], it would be desirable to move the session settings into /sites/default/settings.php so that subsites can have better control over them. One of the advantages of the site specific settings.php file is that it will never get overwritten during upgrades and having these settings here should prove to be more friendly. I have created a patch which moves most of the PHP session settings from .htaccess to /sites/default/settings.php with the exception of "session.auto_start" because it must not, as far as I know, be modified. I have also added 2 additional commented settings which I suspect are often needed as they were in my case. [1] http://drupal.org//node/2974 tangent -- View: http://drupal.org/node/17303 Edit: http://drupal.org/project/comments/add/17303

5 16

RE: [drupal-devel] security "official"
by Boerland Bert 19 Feb '05

19 Feb '05

-----Original Message----- From: drupal-devel-bounces(a)drupal.org > To avoid future problems with security hole reporting, I'd advice creating a > security-team(a)drupal.org (or sg like that) address and advocating it on > drupal.org homepage or at least on the Support page. +1 on this. see parts of http://drupal.org/node/1639 posted nearly 2 years ago. may I suggest altering the email address to security @ drupal.org instead of the team part.

2 1

[drupal-devel] [feature] Add subject to contact module
by kbahey 19 Feb '05

19 Feb '05

Project: Drupal Version: cvs Component: base system Category: feature requests Priority: normal Assigned to: kbahey Reported by: kbahey Updated by: kbahey Status: patch Attachment: http://drupal.org/files/issues/contact.module-subject.patch (1.93 KB) I find it very undescriptive when I recieve a message from Drupal with the subject "message from username". This patch adds a "subject" field for the contact.module which the user can fill, and would tell you what they want right away. Oh, and it helps group the 'conversation' on Gmail into something meaningful. (Note, I have not tested this since I do not have a CVS installation at the moment. Appreciate if someone can test it). kbahey -- View: http://drupal.org/node/16590 Edit: http://drupal.org/project/comments/add/16590

5 8

[drupal-devel] OSCOM info on Drupal
by Ross Kendall 19 Feb '05

19 Feb '05

Not sure if anyone else here pays much attention to what goes on with OSCOM (www.oscom.org)? I have been on their mailing list for a while (couple of years), nothing much usually goes on though, but recently they were asking if there were RSS feeds for Open Source Content Management systems that they should include in there aggregated Blog page http://planet.oscom.org/ I suggested the Drupal feed, which has now been added, so you can now see Drupal front page posts along with Plone, EZ, OpenACS, Midgard, etc. posts. One thing, the Drupal information page in the 'CMS Matrix' http://www.oscom.org/matrix/drupal.html does not have any useful information (although most of them don't). Does anyone have any good suggestions for what could go here? Like a concise summary of features that would be helpful and understandable for people comparing CMSs (like http://www.oscom.org/matrix/lenya.html ) Cheers, Ross.

2 1

[drupal-devel] inconsistency of from_*
by Negyesi Karoly 19 Feb '05

19 Feb '05

Hi! After 4.6 we really should seriously break the API, what would the world come to if there would be no important API changes from one version to the other? We module developers would get lazy. My first proposal is to fix that some form elements have $attributes, some have $extra. This is not really logical to me. Regards NK

3 2

[drupal-devel] cvs tag -b DRUPAL-4-5 problem
by Axel 19 Feb '05

19 Feb '05

Hi. I upload module to contribs CVS and commit it. It's OK. But now I try to branch it for 4.5: $ cd modules/snippets $ cvs tag -b DRUPAL-4-5 cvs tag: warning: directory CVS specified in argument cvs tag: but CVS uses CVS for its own purposes; skipping CVS directory cvs tag: warning: taginfo line contains no format strings: "/cvs/drupal-contrib/CVSROOT/xcvs-taginfo.php /cvs/drupal-contrib/CVSROOT/xcvs-config.php axel" Filling in old defaults ('%t %o %p %{sv}'), but please be aware that this usage is deprecated. Invalid tag for /s/snippets. cvs tag: Pre-tag check failed cvs [tag aborted]: correct the above errors first! Oops :( It not my first upload to contrib and previous modules tagged successfuly, but now I don't tag it anymore. And I got similar problem with csvfilter - I can't add new file to 4.5 branch. Same error appeared. Where am I wrong? -- Alexander Grafov <axel(a)drupal.ru> Drupal Russia - www.drupal.ru

1 0

Re: [drupal-devel] Project management contribs: Bundles: grouped modules.
by Robert Douglass 19 Feb '05

19 Feb '05

I like the idea of having a vetting team which puts together a list of recommended modules. This should be nothing more than a list. If they are stored separately or not is unimportant, the important aspect being that someone who was given the job looked at the work and endorsed it. This is not to say that modules not on the "A" list are bad, but they might take more work to install, or are less stable/tested, or are not as actively supported and developed. Most of us on this list would still download them, install them and make our own decisions. Less capable users would rightfully avoid them. I like the idea of bundles too, but only as a way of suggesting to users what works best. This should in no way be an enforced grouping and should only be an alternative way to select modules. Example: image.module and img_assist.module (4.5 versions). Both would be listed in the "A" list, and in a separate list, a bundle called "image bundle" would offer both together, as well as special instructions for getting them both up and running. This approach has several advantages. First, it takes the best parts of everybody's ideas (so far). Second, it requires very few changes to our current system. Third, we have nothing to lose. We don't lose the good modules that everyone likes, and we don't lose the wild ones which can be pretty bad and useless, but like mentioned already, play an important role in the community. In the end, it is a presentation and packaging problem. The two things which we would change to achive this are: 1) set up a vetting committee and guidelines (not too restrictive - shouldn't become a huge political thing) 2) extend our build process to offer bundle tarballs.

2 1