March 2005 - Development - lists.drupal.org

[drupal-devel] [feature] move check_query() into the database interface files
by chx 10 Mar '05

10 Mar '05

Issue status update for http://drupal.org/node/13180 Project: Drupal Version: cvs Component: database system Category: feature requests Priority: normal Assigned to: chx Reported by: chx Updated by: chx Status: patch Attachment: http://drupal.org/files/issues/mysql_escape_patch_0.txt (573 bytes) OK, here is mysql version a bit corrected, this should get into 4.6 -- addslashes is not a correct way any more. chx Previous comments: ------------------------------------------------------------------------ November 19, 2004 - 20:35 : chx Attachment: http://drupal.org/files/issues/check_output_patch.txt (1.54 KB) The check_query documentation says 'Prepare user input for use in a database query, preventing SQL injection attacks.' But the code itself is a simple addslashes. This is simply not correct -- for mysql, yes, but the world is not just mysql. There are _escape_string functions for that: mysql_escape_string, pg_escape_string, sqlite_escape_string... Read the manual for pg_escape_string: "Use of this function is recommended instead of addslashes()." Or read sqlite_escape_string: "addslashes() should NOT be used to quote your strings for SQLite queries; it will lead to strange results when retrieving your data." Ooooops. So I propose moving check_query() declaration from bootstrap.inc to database.*.inc. I've already written a letter to the devel list about this, but drumm said "code is better than talk" so here is a patch. At this moment, this does absolutely nothing, only opens the possibility to use the aforementioned escape_string functions. But database.sqlite.inc simply will not work without this change. ------------------------------------------------------------------------ November 19, 2004 - 20:42 : drumm Looks straightfoward enough. Is there any reason to not put in pg_escape_string() now? ------------------------------------------------------------------------ November 19, 2004 - 20:47 : chx Actually, yes. Read on the mentioned manual page: "Note: This function requires PostgreSQL 7.2 or later." I have no idea how the check it. There is a pg_version() but I will leave this postgres business to someone who has a working postgres install to code and check this thing. ------------------------------------------------------------------------ November 19, 2004 - 21:58 : Chris Johnson PostgreSQL 7.2 was released February 4, 2002. Major production releases 73. and 7.4, along with many point releases, have been issued since then. Current production is 7.4.6 and 8.0 is in the 4th revision of beta. It seems pretty safe to assume that any Drupal installation using PostgreSQL would have version 7.2 or later. Document if a user encounters errors with PostgreSQL that they need to check the version is 7.2 or later. ------------------------------------------------------------------------ November 20, 2004 - 14:42 : Dries +1 I suggest creating a db_escape_string() function, and removing check_query() all together. ------------------------------------------------------------------------ November 20, 2004 - 14:55 : Goba +1 on Dries ------------------------------------------------------------------------ November 20, 2004 - 18:32 : chx Attachment: http://drupal.org/files/issues/check_output_patch_0.txt (1.6 KB) db_escape_string sounds find to me, it's really a better name, thanks Dries. But removing check_query? I'd suggest deprecating it and removing it later. I am afraid It would break a lot of custom modules. Here is a slightly modified patch with pg_escape_string included and documented. ------------------------------------------------------------------------ November 20, 2004 - 18:43 : killes(a)www.drop.org We were never afraid of breakign things for the good of the project. Please don't change this policy. ------------------------------------------------------------------------ November 20, 2004 - 19:26 : chx Attachment: http://drupal.org/files/issues/db_escape_string.txt (20.87 KB) Let's do it. ------------------------------------------------------------------------ November 20, 2004 - 19:29 : chx Attachment: http://drupal.org/files/issues/db_escape_string_0.txt (20.88 KB) Something funny happened to the PostgreSQL db_escape_string comment and I have missed it, sorry. Reposting the patch. ------------------------------------------------------------------------ November 21, 2004 - 09:29 : Dries I committed the patch. Thanks chx. Keep it coming. I've also updated the upgrade notes at http://drupal.org/node/12347. I'll update some contributed modules unless someone objects. ------------------------------------------------------------------------ November 21, 2004 - 12:27 : chx Attachment: http://drupal.org/files/issues/mysql_escape_patch.txt (572 bytes) Keep it coming? Well, let's see the MySQL case... It's far from being trivial, and I expect some controversy over it.

1 0

[drupal-devel] Release critical bugs for March 09, 2005
by drupal-devel＠drupal.org 09 Mar '05

09 Mar '05

Bbcode / bug reports email spam filtering does not "see" email addresses when they are NOT preceded by a word age: 7 weeks 4 days url: http://drupal.org/node/15654 Buddylist / bug reports SQL errors using HEAD from CVS age: 1 week 1 day url: http://drupal.org/node/18160 Chatbox / support requests Cron run kills Chat? age: 13 weeks 1 day url: http://drupal.org/node/14032 Drupal / bug reports New submit error, non-admin user, postgresql database age: 1 day 5 hours url: http://drupal.org/node/18552 Module-specific taxonomony support breaks existing sites assigned: walkah age: 3 days 4 hours url: http://drupal.org/node/18471 Durpal page crashes Mozilla, perhaps due to malformed HTML age: 1 week 8 hours url: http://drupal.org/node/18248 PHP 4.3.11 and upload in IE age: 2 weeks 4 days url: http://drupal.org/node/17595 When I delete a user, any forum in which s/he has commented also disappears. assigned: Jill6q age: 3 weeks 3 hours url: http://drupal.org/node/17428 problems with admin/user/configure/permission and 4.5.2 age: 3 weeks 3 days url: http://drupal.org/node/17282 node preview broken -- no clone() function age: 4 weeks 1 day url: http://drupal.org/node/16958 Published poll doesnt show up in poll block if in submission queue age: 4 weeks 6 days url: http://drupal.org/node/16671 Adding two custom blocks with the same name produces a sql warning age: 4 weeks 6 days url: http://drupal.org/node/16659 Cache-Control header not set age: 5 weeks 6 days url: http://drupal.org/node/16295 updates.inc deleting profile_data when updating age: 7 weeks 3 days url: http://drupal.org/node/15686 Change to sesssion.inc violates UID database constraint age: 7 weeks 3 days url: http://drupal.org/node/15666 problem with forum.module with postgresql v7.4.1 age: 8 weeks 2 days url: http://drupal.org/node/15412 forum.module problem with postgresql v7.4.1 age: 8 weeks 2 days url: http://drupal.org/node/15411 PHP 5 gives error when session table has no session assigned: adschar age: 8 weeks 2 days url: http://drupal.org/node/15399 postgresql error age: 8 weeks 6 days url: http://drupal.org/node/15175 UID 0, anonymous user account deleted age: 13 weeks 3 days url: http://drupal.org/node/13915 Entering an empty title broke drupal age: 16 weeks 2 days url: http://drupal.org/node/12974 Argument NOT must be type boolean age: 16 weeks 2 days url: http://drupal.org/node/12950 Comments in approval queue still show up in tracker age: 20 weeks 4 days url: http://drupal.org/node/11647 Twin problems with comments assigned: Junyor age: 21 weeks 6 days url: http://drupal.org/node/11366 Prevent browser page caching of dynamic content assigned: mathias age: 1 year 3 weeks url: http://drupal.org/node/5900 Drupal / feature requests Taxonomy module should use nodeapi 'load' age: 3 hours 6 min url: http://drupal.org/node/18631 Auto PHP memory maximisation age: 2 weeks 2 days url: http://drupal.org/node/17663 Don't reset existing password on request, prevent DoS password reset abuse age: 4 weeks 2 days url: http://drupal.org/node/16909 User info exposed to anonymous user age: 14 weeks 4 days url: http://drupal.org/node/13545 Allow named anchors to work without specifying full path to node age: 1 year 15 weeks url: http://drupal.org/node/4213 Drupal / support requests user redirected to homepage when logging in age: 5 days 3 hours url: http://drupal.org/node/18381 Problem with Forums age: 8 weeks 4 days url: http://drupal.org/node/15299 Drupal / tasks atom.module working version to 4.5.0 assigned: hugoromano age: 18 weeks 6 hours url: http://drupal.org/node/12496 Postgres Compatibility Update assigned: adrian age: 24 weeks 2 days url: http://drupal.org/node/10945 Drupal.org maintenance / bug reports drupaldocs.org and large fonts age: 5 days 7 hours url: http://drupal.org/node/18367 Konqueror problem age: 4 weeks 2 days url: http://drupal.org/node/16913 screenshots : page not found age: 4 weeks 5 days url: http://drupal.org/node/16752 Large Fonts problems age: 4 weeks 6 days url: http://drupal.org/node/16664 I can not add a release of Chinese Simplified Translation. age: 20 weeks 10 hours url: http://drupal.org/node/11770 Drupal.org maintenance / feature requests Plain text posting age: 3 weeks 2 days url: http://drupal.org/node/17335 Event / bug reports bad arguments in theme.inc age: 1 hour 15 min url: http://drupal.org/node/18642 Doesn't work with i18n hack/module age: 1 week 1 day url: http://drupal.org/node/18145 search over fields.inc fields conceptual error age: 18 weeks 5 days url: http://drupal.org/node/12259 fields.inc screws up with multible multiselect fields age: 18 weeks 5 days url: http://drupal.org/node/12257 Still GMT/TZ issues with CVS age: 19 weeks 6 days url: http://drupal.org/node/11870 Time entry is GMT even when site default is not age: 20 weeks 4 days url: http://drupal.org/node/11630 Start Time of Event is NOT Preserved age: 37 weeks 6 days url: http://drupal.org/node/8565 Feature / bug reports Menu item not showing age: 22 weeks 5 days url: http://drupal.org/node/11210 File / bug reports segmentation fault related to filestore age: 1 year 23 weeks url: http://drupal.org/node/3001 Filebrowser / bug reports em.. out of root? age: 16 hours 48 min url: http://drupal.org/node/18596 Filestore / support requests File store module - Overwriting Filename....Help needed assigned: harishkm age: 49 weeks 11 hours url: http://drupal.org/node/6827 Unserialize error at line 104 age: 1 year 3 weeks url: http://drupal.org/node/5857 Filestore module- sql errors rectified assigned: harishkm age: 1 year 4 weeks url: http://drupal.org/node/5619 Filestore Module Problems unaddressed assigned: harishkm age: 1 year 6 weeks url: http://drupal.org/node/5365 Gallery / bug reports "Cannot modify header information" age: 3 days 12 hours url: http://drupal.org/node/18457 Fatal error: Undefined class name 'galleryembed' age: 2 weeks 1 day url: http://drupal.org/node/17746 Gallery / support requests Can't Embed Gallery into Drupal age: 1 week 3 days url: http://drupal.org/node/18029 Goofy / bug reports Blocks with no name age: 4 weeks 3 days url: http://drupal.org/node/16860 Groups / bug reports Drupal-4.4-rc breaks registration setups and groups.module age: 51 weeks 5 days url: http://drupal.org/node/6392 Image / bug reports Cannot upload .jpgs age: 1 week 2 days url: http://drupal.org/node/18076 Wrongly formed html in image gallery age: 2 weeks 6 days url: http://drupal.org/node/17462 Image.Module does not know the correct filename age: 16 weeks 1 day url: http://drupal.org/node/13032 SAFE MODE Restriction in effect... age: 19 weeks 6 days url: http://drupal.org/node/11843 Uploading jpeg makes Imagemagick do high compression age: 21 weeks 3 days url: http://drupal.org/node/11445 Image module failing on Preview because of a blank node id age: 23 weeks 4 days url: http://drupal.org/node/11069 Similar problem with Directory Upload Slow age: 23 weeks 4 days url: http://drupal.org/node/11064 Node Aggregator / bug reports Import doesn't like XML/RSS feeds with no Title element age: 40 weeks 4 days url: http://drupal.org/node/8128 Node Aggregator / feature requests RSS items overwriting edited items age: 38 weeks 5 days url: http://drupal.org/node/8455 Notify / feature requests Notify.module ignores the true submission queue age: 1 year 19 weeks url: http://drupal.org/node/3765 Online / support requests Need Help age: 2 weeks 6 days url: http://drupal.org/node/17475 Pdfview / feature requests Internationalization support for PDF assigned: TheLibrarian age: 49 weeks 1 day url: http://drupal.org/node/6795 Project / bug reports Invalid link to release files age: 2 weeks 3 days url: http://drupal.org/node/17625 blank page after install age: 5 weeks 1 day url: http://drupal.org/node/16575 "Page Not Found" when trying to view issues or add new release age: 13 weeks 6 days url: http://drupal.org/node/13815 Project pages display only title and description age: 16 weeks 1 hour url: http://drupal.org/node/13082 Fatal error: Cannot use string offset as an array in includes/tablesort.inc on line 113 assigned: publian age: 22 weeks 6 days url: http://drupal.org/node/11187 Can't create new project with issue tracker age: 29 weeks 15 hours url: http://drupal.org/node/10148 Project / support requests Help with everything - nothing seems to work in the latest build age: 15 weeks 2 days url: http://drupal.org/node/13310 Taxonomy dhtml / bug reports javascrip downloads square.gif for every category age: 3 weeks 1 day url: http://drupal.org/node/17366 TrackBack / bug reports Sends trackbacks for unpublished nodes age: 6 weeks 2 hours url: http://drupal.org/node/16239 Overly aggressive age: 13 weeks 5 days url: http://drupal.org/node/13865 trackback borks google and every other search engine age: 18 weeks 2 days url: http://drupal.org/node/12388 User experience / bug reports user interface problem http://drupal.org/forum/1?from=25 age: 1 week 13 hours url: http://drupal.org/node/18237 User experience / tasks WorkFlow and Action Module age: 2 weeks 5 days url: http://drupal.org/node/17517 Weblink / bug reports node_access_join_sql() error age: 20 min 21 sec url: http://drupal.org/node/18646 Weblink / feature requests Display of child categories on the weblink directory default page age: 3 weeks 6 days url: http://drupal.org/node/17132 Display of child categories on the weblink directory default page age: 3 weeks 6 days url: http://drupal.org/node/17130

1 0

Re: [drupal-devel] promote to frontpage: confusing.
by Ross Kendall 09 Mar '05

09 Mar '05

makes sense to me Andre Molnar wrote: > Pseudo code: > > If($default_front_page) { > form_checkboxes(t('Promote to front page') /*MORE CODE*/); > } > else { > /*DO NOTHING - PROBLEM SOLVED - NO SEMANTIC TRAPS - LETS STOP > THIS ENTIRE THREAD*/ > } > > andre > > >

3 2

[drupal-devel] promote to frontpage: confusing.
by Bèr Kessels 09 Mar '05

09 Mar '05

Hello. Currently we use the standard flag called "promote to frontpage". This is only correct for those cases where /node is the frontpage. For all other cases, thes flag is obsolete, if not completely wrong. I suggest the folloiwing: We stop calling /node frontpage. We call /node "headlines", in documentation and help text. By default the headlines are set to frontpage (we have that now) We rename the flag " promote" to "add to healines", or even simply "is headline" Pro This will improve useability for all these ppl that do not use /node as frontpage. It will make our frontpage system clearer, for /node (headlines) becomes just another frontpage option. Con: Users who are used to the current system might get confused when they do not find the "promote to frontpage flag" anymore. Regards, Bèr -- [ Bèr Kessels | Drupal services www.webschuur.com ]

12 31

[drupal-devel] [feature] Improved help language for description of container
by nysus 09 Mar '05

09 Mar '05

Issue status update for http://drupal.org/node/18465 Project: Drupal Version: cvs Component: forum.module Category: feature requests Priority: normal Assigned to: Anonymous Reported by: nysus Updated by: nysus Status: patch Attachment: http://drupal.org/files/issues/forum_5.patch (1.34 KB) Improvement to description of what a container is. Made it more readable and understandable for non-techies and people new to Drupal. nysus

2 2

[drupal-devel] Drupal executes stuff in .inc files
by Gerhard Killesreiter 09 Mar '05

09 Mar '05

Hi there! One of the problems that our Debian packager has had is that for example the update script includes bootstrap.inc and common.inc. These in turn include severayl other .inc files. In three of these files (bootstrap, common, and session) there is php code that does not only define new functions, but also executes them. This is pretty annoying, as it for example starts a session which you might not want and initializes several parts of Drupal you might prefer to not execute for some reason. You'd however still like all the common.inc functions to be available. This will be neccessary to create a php solution for downloading protected files without executing all of Drupal again. In the attached patch, I've moved all the functions that should be executed into index.php. This is again not ideal, as for example my generate scripts will need to copy quite some code from index.php with this patch. Ideally we'd have a bootstrap-exec.php and a common-exec.php file that would hold all this function calls, leaving only the session functions in index.php. I believe that this approach might be helpfull for Adrian's installer as well. Comments? Cheers, Gerhard

3 2

[drupal-devel] A Folksonomy module
by Julian Bond 09 Mar '05

09 Mar '05

I've been thinking a lot and writing code to experiment with a Folksonomy module. The long term goal is a parallel to Taxonomy that can be used alongside or instead of Taxonomy. It would provide a free form text field(s) on nodes that let the user enter comma-separated keyword tags in a del.ico.us style. There are two use cases for this. 1) General classification and navigation of internal Drupal objects. Presumably this means exclusively nodes. 2) Various group classifications of external objects to duplicate del.icio.us functionality for a Drupal site's community. I think, but I'm not sure that this is exactly the same as 1) There are a number of key ideas taken from current folksonomy projects on the web. These tend to be database intensive. - Using clustering analysis to derive "popular" tags. - Similarly to derive "related" tags. - Navigation via an information block about the current tag page containing; search; my tags; popular tags; tags related to this one. - Faceted search to drill down on multiple parameters. - Innovative data entry support. eg; one click adding of existing tags from a list; Google Suggest style on the fly updating of suggested tags based on what's been entered so far. There's also quite a lot of knotty questions around things like access rights. - Should only the author be able to add tags to a node? - Can the administrator prune and clean the developing tag vocabulary? - Does it need synonym support? - Does "tag spam" need controlling to stop a user polluting the vocabulary by adding 250 tags to a node? So how to move forwards with this? Moshe's folksonomy module is currently really just a placeholder (no offence Moshe!). I think there's an assumption in there that a node would only have a single tag from a particular Realm (folksonomy->realm ~= taxonomy-vocabulary). This doesn't look right to me. I would expect most nodes to have 2 or 3 and perhaps 10 tags from a realm. I've found it impossible to add the next iteration to Moshe's code without at least doubling the amount of code and reworking the database table(s). The next step is a biggish one. The Taxonomy on the fly module really isn't the same. The key bit of del.icio.us style tagging is the free form entry of multiple keywords. There should be no onus on the user to force them to select from a list and create new entries in the list if one's missing. It should just happen. Some of the parallels with taxonomy mean that you end up cutting, pasting and reworking large amounts of Taxonomy code. And because Taxonomy has been around for a long time there's quite a few places where Taxonomy is treated as core and modules have specific support for it. Which is not a problem except that a folksonomy module would want to be similarly treated as special. Which suggests that perhaps Folksonomy should be a development of Taxonomy. Perhaps there's a new vocabulary type "folks" which has free form tags instead of a tree. Working against that is that it's sufficiently different that a lot of Taxonomy code would have to be duplicated anyway. I also think this is too unformed yet and so at least to start with it should be done in the sandbox of a contributed module. Maybe later it can be merged into Taxonomy. So anyway, my second attempt at this is much more Drupal style and extends folksonomy.module. But it extends it enough and makes enough new assumptions that I really need to talk about this before careering off into left field. ps. The hidden agenda in all this is a tag based Craigslist clone built in Drupal. But that's another story. ;-) -- Julian Bond Email&MSM: julian.bond at voidstar.com Webmaster: http://www.ecademy.com/ Personal WebLog: http://www.voidstar.com/ M: +44 (0)77 5907 2173 T: +44 (0)192 0412 433 S: callto://julian.bond/

9 20

[drupal-devel] [bug] Prevent browser page caching of dynamic content
by Bèr Kessels 09 Mar '05

09 Mar '05

Issue status update for http://drupal.org/node/5900 Project: Drupal Version: cvs Component: user system Category: bug reports Priority: critical Assigned to: mathias Reported by: christianlong(a)christianlong.com Updated by: Bèr Kessels Status: patch +1 from me. Nice clean patch. Works in FF and konq, cannot test in IE, which has very aggressive caching, AFAIK. Bèr Kessels 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). ------------------------------------------------------------------------ February 19, 2005 - 19:52 : killes(a)www.drop.org This patch only affects users of mod_expires and harms nobody else. +1 ------------------------------------------------------------------------ February 21, 2005 - 05:01 : Steven Applied to CVS. Do we still need our own Cache Control mechanism? I'm included to let the server handle this. ------------------------------------------------------------------------ March 9, 2005 - 07:27 : mathias Attachment: http://drupal.org/files/issues/control-browser-caching.patch (713 bytes) Browsers are sometimes pulling files from their cache and serving stale pages when instead they should be asking the server for a new copy. This is because Drupal doesn't issue its own Cache-Control headers like most other CMS's [7]. Instead those details are currently left up to each server, which users on shared hosting aren't authorized to configure. This bug rears it's ugly head when site admins use Drupal's caching mechanism. If a user clicks on the homepage after logging in, they're very likely to see a stale unauthenticated view. Or if they log out and returns to the homepage, it'll appear that they're still logged in. But perhaps the most confusing of these caching issues is when you click the login button and are once again presented with the same login form. These cached views are occurring because the browser still thinks those pages are valid in it's cache. In otherwards, it's sending if-Modified-Since headers and receiving a valid HTTP 304 response. Now this doesn't happen 100% of the time in all cases. It very much depends on the browser (usually Firefox or Safari but never Konqueror) and how the server is configured (Mac OS X server can be quite troublesome for example while a default FreeBSD install of apache usually sends the proper headers). The most elegant solution I've come up with is to issue our own Cache-Control headers after a request has been cached by Drupal's caching mechanism. The header workflow then becomes: // User requests a page that isn't in the Drupal cache table HTTP 200 (server issues it's own caching headers) // User requests the same page (now in the cache table) HTTP 200 (Drupal issues it's own caching headers explicitly stating not to cache the page) // User requests the same page (now in the cache table) HTTP 304 (server issues it's own caching headers) If I'm understanding how things work, this lets the browser use the cached page only as long as we're sending 304 responses. When the user logs in, the browser cache is invalidated since a different set of headers are emitted, causing the stale copies to expire. The end result is that browsers are still allowed to do caching of requests (including XML feeds) but only hold on to those copies until Drupal says otherwise. [7] http://asitis.org/tmp/cms_cache_review.txt ------------------------------------------------------------------------ March 9, 2005 - 07:37 : chx +1

1 0

Antwort: Re: [drupal-devel] HTMLArea is dead, long live rich text editing [Virus checked]
by Denis.Havlik＠t-mobile.at 09 Mar '05

09 Mar '05

FYI: Paragraf 3 of the LGPL entitled you to take any (part of the) LGPL-ed library, and publish it again under GPL if you want, or if you have to in order to merge the (parts of) the library into GPL-ed program. This was done with the purpose of clearing the doubts about the compatibility of the two licences. http://www.gnu.org/copyleft/lesser.html "3) You may opt to apply the terms of the ordinary GNU General Public License instead of this License to a given copy of the Library...." This of course causes problems with sending bug fixes back to original work, so I wouldn't execute this right unless something terrible happens to original project (premature death, licence change). cheers Denis -- T-Mobile Austria GmbH, Information Technologies / Services Knowledge Management & Process Automation Dr. Denis Havlik, eMail: denis.havlik(a)t-mobile.at Rennweg 97-99, BT2E0304031 Phone: +43-1-79-585/6237 A-1030 Vienna Fax: +43-1-79-585/6584 Mark <mark(a)nullcraft.org> Gesendet von: drupal-devel-bounces(a)drupal.org 09.03.2005 03:38 Bitte antworten an drupal-devel An: drupal-devel(a)drupal.org Kopie: Thema: Re: [drupal-devel] HTMLArea is dead, long live rich text editing [Virus checked] Negyesi Karoly wrote: >>TinyMCE looks promising, and worked surprisingly well on FreeBSD/Firefox. >> >> > >TinyMCE is [...] released [...] under LGPL > >Do we accept Lesser GPL? > > AFAIK, LGPL is perfectly compatible with GPL projects from a legal standpoint, considering we would just be including it as a library in a GPL project. -Mark

1 0

[drupal-devel] [bug] Prevent browser page caching of dynamic content
by chx 09 Mar '05

09 Mar '05

Issue status update for http://drupal.org/node/5900 Project: Drupal Version: cvs Component: user system Category: bug reports Priority: critical Assigned to: mathias Reported by: christianlong(a)christianlong.com Updated by: chx Status: patch +1 chx 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). ------------------------------------------------------------------------ February 19, 2005 - 19:52 : killes(a)www.drop.org This patch only affects users of mod_expires and harms nobody else. +1 ------------------------------------------------------------------------ February 21, 2005 - 05:01 : Steven Applied to CVS. Do we still need our own Cache Control mechanism? I'm included to let the server handle this. ------------------------------------------------------------------------ March 9, 2005 - 07:27 : mathias Attachment: http://drupal.org/files/issues/control-browser-caching.patch (713 bytes) Browsers are sometimes pulling files from their cache and serving stale pages when instead they should be asking the server for a new copy. This is because Drupal doesn't issue its own Cache-Control headers like most other CMS's [7]. Instead those details are currently left up to each server, which users on shared hosting aren't authorized to configure. This bug rears it's ugly head when site admins use Drupal's caching mechanism. If a user clicks on the homepage after logging in, they're very likely to see a stale unauthenticated view. Or if they log out and returns to the homepage, it'll appear that they're still logged in. But perhaps the most confusing of these caching issues is when you click the login button and are once again presented with the same login form. These cached views are occurring because the browser still thinks those pages are valid in it's cache. In otherwards, it's sending if-Modified-Since headers and receiving a valid HTTP 304 response. Now this doesn't happen 100% of the time in all cases. It very much depends on the browser (usually Firefox or Safari but never Konqueror) and how the server is configured (Mac OS X server can be quite troublesome for example while a default FreeBSD install of apache usually sends the proper headers). The most elegant solution I've come up with is to issue our own Cache-Control headers after a request has been cached by Drupal's caching mechanism. The header workflow then becomes: // User requests a page that isn't in the Drupal cache table HTTP 200 (server issues it's own caching headers) // User requests the same page (now in the cache table) HTTP 200 (Drupal issues it's own caching headers explicitly stating not to cache the page) // User requests the same page (now in the cache table) HTTP 304 (server issues it's own caching headers) If I'm understanding how things work, this lets the browser use the cached page only as long as we're sending 304 responses. When the user logs in, the browser cache is invalidated since a different set of headers are emitted, causing the stale copies to expire. The end result is that browsers are still allowed to do caching of requests (including XML feeds) but only hold on to those copies until Drupal says otherwise. [7] http://asitis.org/tmp/cms_cache_review.txt

1 0