May 2005 - Development - lists.drupal.org

[drupal-devel] [feature] Add timing information to statistics page
by Jeremy 12 May '05

12 May '05

Issue status update for http://drupal.org/node/22623 Project: Drupal Version: cvs Component: statistics.module Category: feature requests Priority: normal Assigned to: Anonymous Reported by: Dries Updated by: Jeremy(a)kerneltrap.org Status: patch I love the idea very much, and think this will prove extremely useful. What about making an option that enables/disables these columns? The only reason I suggest this is because they are inherently confusing without using a lot of verbage. "Average time" needs to be something like "Average time for Drupal engine to generate this page", and "Total time" needs to be something like "Total time to generate". Or, it could be fully explained at the configurable that turns the display on and off...? ""I could easily compile a list of the users/IPs that eat most resources." " Yes, do it! :) That would be very useful. ""Would it be possible to support batching the log entries and submitting them to the database as batch query at set increments instead of for every page." " Where would the data be stored until it was committed to the table? It would be possible to do something similar to what the banner module does, writing to multiple cache files. But this isn't friendly for distributed web servers. Do writes to the accesslog slow down measurably when the acceslog table grows? If so, then there could be an accesslog_cache table to which data is first written, and which is flushed to the main accesslog every n minutes, or every time it reaches a certain size, etc. This would only be useful if writing to a very large table is measurably slower than writing to a very small table. Jeremy(a)kerneltrap.org Previous comments: ------------------------------------------------------------------------ May 11, 2005 - 15:05 : Dries Attachment: http://drupal.org/files/issues/timer.patch (8.56 KB) I extended the current timer_start() function in bootstrap.inc and added two new function, timer_read() and timer_stop(). I've used these to profile drupal.org. (A small change will be needed to devel.module.) I've also extended the accesslog-table to keep track of page generation times. The information is shown on the "top pages" page (admin/logs/pages). It shows each page's average page generation time, and the total page generation time. This lets one identify (i) slow pages and (ii) resource heavy pages. This is the most essential and most useful information when tuning your Drupal site. Please review, or I'll commit it as is. ------------------------------------------------------------------------ May 11, 2005 - 15:13 : Dries Attachment: http://drupal.org/files/issues/timer.pdf (22 KB) Screenshot. ------------------------------------------------------------------------ May 11, 2005 - 16:04 : Dries Setting to patch. Take a look at the patch + screenshot please. ------------------------------------------------------------------------ May 11, 2005 - 16:19 : moshe weitzman looks ok ... note that there are some unrelated (i think) variable_set() changes in the patch. ------------------------------------------------------------------------ May 11, 2005 - 16:20 : Amazon It's great to have this level of logging granularity. I am concerned that all the logging would add over head when having multiple crawlers crawling the site during testing. Would it be possible to support batching the log entries and submitting them to the database as batch query at set increments instead of for every page. For example I routinely run several wget crawls for different roles when testing an upgrade. If I ran 5 crawlers and each of 10, 000+ pages were being crawled then I am concerned the performance would be impacted. I understand this isn't the intent of this patch but non intrusive logging is important in generating accurate performance measurements. Thank-you for your consideration. Kieran ------------------------------------------------------------------------ May 11, 2005 - 16:20 : moshe weitzman in the pdf, i think you are swapping 'total' and 'average' column headers ------------------------------------------------------------------------ May 11, 2005 - 16:34 : Bèr Kessels I like the idea. a lot. But from the pdf it is not clear that timer deals with the generation tilme o a page. * Are we not boing too geeky here (again)? devel.module does farily granual timing already. Is Joe User really waiting for timers on how long it took to make a page. I think not. * If we really want this in core, it should at least be made very clear that this is the time it took to make a page. I presented the screenshot to a client, as a small test. And just like i thought, his reaction was " Wow, this is handy, I can now see how long a user spent at a certain page. This will tell me what posts are actually read, and which are only opened in a browser only to be closed right away". I almost made the same mistake, but the geek in me told me to look at the code and see that it is page generation times. Joe user will not ever look at the code. * What is the penalty. accesslog already is a heavy load table. Do we really want aditional data in that table. * We have access hooks (called after page is loaded) to do aditional statistics magic. IT is not userd by anything else then the stats in core. Why cant this go into an advanced stats module? ------------------------------------------------------------------------ May 11, 2005 - 17:03 : Dries Moshe: the column names are not swapped. What makes you think they are? What can be done to make it more clear? Moshe: the variable_get() was removed intentionally. The 'page' timer is always started. It's cheap. Ber: I'm aware of the possible confusion and I agree that we need to clarify this. Unfortunately, I couldn't think of better column names. The problem is that these names should be short (or the table will look ugly). Suggestions? Ber: the devel.module does not provide this functionality. It doesn't track page generation times for other users, it doesn't compute averages, nor does it compute the total time spent generating a particular page. The devel.module doesn't have an overview. This is important information for anyone who has to tune his or her Drupal site. Without this patch, you simply don't know which pages are eating your resources. Ber, Kieran: the performance impact is small. The timer values are stored as integers and fit in 2 bytes. So if there are 200.000 entries in your accesslog-table like on drupal.org, the database overhead is 400kb (a fraction of the table's total size). No additional SQL queries are introduced. As such, performance remains comparable with the current implementation. I can benchmark this if you want but I'm confident it is OK. I could easily compile a list of the users/IPs that eat most resources. This can help us track evil crawlers. I'm not sure yet how or where to integrate this UI-wise so I haven't (yet). One step at a time. Making it easy to inspect the performance characteristics of your Drupal site is a good thing. It creates awareness which in turn will encourage people to tune and tweak Drupal's performance. It also lets you identify problems -- like a module performing badly. Compare it with your operating system's "activity/process monitor" (or "top"). You don't really need it, but you can't without it either.

1 0

[drupal-devel] [feature] Add timing information to statistics page
by Dries 12 May '05

12 May '05

Issue status update for http://drupal.org/node/22623 Project: Drupal Version: cvs Component: statistics.module Category: feature requests Priority: normal Assigned to: Anonymous Reported by: Dries Updated by: Dries Status: patch Moshe: the column names are not swapped. What makes you think they are? What can be done to make it more clear? Moshe: the variable_get() was removed intentionally. The 'page' timer is always started. It's cheap. Ber: I'm aware of the possible confusion and I agree that we need to clarify this. Unfortunately, I couldn't think of better column names. The problem is that these names should be short (or the table will look ugly). Suggestions? Ber: the devel.module does not provide this functionality. It doesn't track page generation times for other users, it doesn't compute averages, nor does it compute the total time spent generating a particular page. The devel.module doesn't have an overview. This is important information for anyone who has to tune his or her Drupal site. Without this patch, you simply don't know which pages are eating your resources. Ber, Kieran: the performance impact is small. The timer values are stored as integers and fit in 2 bytes. So if there are 200.000 entries in your accesslog-table like on drupal.org, the database overhead is 400kb (a fraction of the table's total size). No additional SQL queries are introduced. As such, performance remains comparable with the current implementation. I can benchmark this if you want but I'm confident it is OK. I could easily compile a list of the users/IPs that eat most resources. This can help us track evil crawlers. I'm not sure yet how or where to integrate this UI-wise so I haven't (yet). One step at a time. Making it easy to inspect the performance characteristics of your Drupal site is a good thing. It creates awareness which in turn will encourage people to tune and tweak Drupal's performance. It also lets you identify problems -- like a module performing badly. Compare it with your operating system's "activity/process monitor" (or "top"). You don't really need it, but you can't without it either. Dries Previous comments: ------------------------------------------------------------------------ May 11, 2005 - 22:05 : Dries Attachment: http://drupal.org/files/issues/timer.patch (8.56 KB) I extended the current timer_start() function in bootstrap.inc and added two new function, timer_read() and timer_stop(). I've used these to profile drupal.org. (A small change will be needed to devel.module.) I've also extended the accesslog-table to keep track of page generation times. The information is shown on the "top pages" page (admin/logs/pages). It shows each page's average page generation time, and the total page generation time. This lets one identify (i) slow pages and (ii) resource heavy pages. This is the most essential and most useful information when tuning your Drupal site. Please review, or I'll commit it as is. ------------------------------------------------------------------------ May 11, 2005 - 22:13 : Dries Attachment: http://drupal.org/files/issues/timer.pdf (22 KB) Screenshot. ------------------------------------------------------------------------ May 11, 2005 - 23:04 : Dries Setting to patch. Take a look at the patch + screenshot please. ------------------------------------------------------------------------ May 11, 2005 - 23:19 : moshe weitzman looks ok ... note that there are some unrelated (i think) variable_set() changes in the patch. ------------------------------------------------------------------------ May 11, 2005 - 23:20 : Amazon It's great to have this level of logging granularity. I am concerned that all the logging would add over head when having multiple crawlers crawling the site during testing. Would it be possible to support batching the log entries and submitting them to the database as batch query at set increments instead of for every page. For example I routinely run several wget crawls for different roles when testing an upgrade. If I ran 5 crawlers and each of 10, 000+ pages were being crawled then I am concerned the performance would be impacted. I understand this isn't the intent of this patch but non intrusive logging is important in generating accurate performance measurements. Thank-you for your consideration. Kieran ------------------------------------------------------------------------ May 11, 2005 - 23:20 : moshe weitzman in the pdf, i think you are swapping 'total' and 'average' column headers ------------------------------------------------------------------------ May 11, 2005 - 23:34 : Bèr Kessels I like the idea. a lot. But from the pdf it is not clear that timer deals with the generation tilme o a page. * Are we not boing too geeky here (again)? devel.module does farily granual timing already. Is Joe User really waiting for timers on how long it took to make a page. I think not. * If we really want this in core, it should at least be made very clear that this is the time it took to make a page. I presented the screenshot to a client, as a small test. And just like i thought, his reaction was " Wow, this is handy, I can now see how long a user spent at a certain page. This will tell me what posts are actually read, and which are only opened in a browser only to be closed right away". I almost made the same mistake, but the geek in me told me to look at the code and see that it is page generation times. Joe user will not ever look at the code. * What is the penalty. accesslog already is a heavy load table. Do we really want aditional data in that table. * We have access hooks (called after page is loaded) to do aditional statistics magic. IT is not userd by anything else then the stats in core. Why cant this go into an advanced stats module?

1 0

[drupal-devel] [feature] Add timing information to statistics page
by Bèr Kessels 11 May '05

11 May '05

Issue status update for http://drupal.org/node/22623 Project: Drupal Version: cvs Component: statistics.module Category: feature requests Priority: normal Assigned to: Anonymous Reported by: Dries Updated by: Bèr Kessels Status: patch I like the idea. a lot. But from the pdf it is not clear that timer deals with the generation tilme o a page. * Are we not boing too geeky here (again)? devel.module does farily granual timing already. Is Joe User really waiting for timers on how long it took to make a page. I think not. * If we really want this in core, it should at least be made very clear that this is the time it took to make a page. I presented the screenshot to a client, as a small test. And just like i thought, his reaction was " Wow, this is handy, I can now see how long a user spent at a certain page. This will tell me what posts are actually read, and which are only opened in a browser only to be closed right away". I almost made the same mistake, but the geek in me told me to look at the code and see that it is page generation times. Joe user will not ever look at the code. * What is the penalty. accesslog already is a heavy load table. Do we really want aditional data in that table. * We have access hooks (called after page is loaded) to do aditional statistics magic. IT is not userd by anything else then the stats in core. Why cant this go into an advanced stats module? Bèr Kessels Previous comments: ------------------------------------------------------------------------ May 11, 2005 - 21:05 : Dries Attachment: http://drupal.org/files/issues/timer.patch (8.56 KB) I extended the current timer_start() function in bootstrap.inc and added two new function, timer_read() and timer_stop(). I've used these to profile drupal.org. (A small change will be needed to devel.module.) I've also extended the accesslog-table to keep track of page generation times. The information is shown on the "top pages" page (admin/logs/pages). It shows each page's average page generation time, and the total page generation time. This lets one identify (i) slow pages and (ii) resource heavy pages. This is the most essential and most useful information when tuning your Drupal site. Please review, or I'll commit it as is. ------------------------------------------------------------------------ May 11, 2005 - 21:13 : Dries Attachment: http://drupal.org/files/issues/timer.pdf (22 KB) Screenshot. ------------------------------------------------------------------------ May 11, 2005 - 22:04 : Dries Setting to patch. Take a look at the patch + screenshot please. ------------------------------------------------------------------------ May 11, 2005 - 22:19 : moshe weitzman looks ok ... note that there are some unrelated (i think) variable_set() changes in the patch. ------------------------------------------------------------------------ May 11, 2005 - 22:20 : Amazon It's great to have this level of logging granularity. I am concerned that all the logging would add over head when having multiple crawlers crawling the site during testing. Would it be possible to support batching the log entries and submitting them to the database as batch query at set increments instead of for every page. For example I routinely run several wget crawls for different roles when testing an upgrade. If I ran 5 crawlers and each of 10, 000+ pages were being crawled then I am concerned the performance would be impacted. I understand this isn't the intent of this patch but non intrusive logging is important in generating accurate performance measurements. Thank-you for your consideration. Kieran ------------------------------------------------------------------------ May 11, 2005 - 22:20 : moshe weitzman in the pdf, i think you are swapping 'total' and 'average' column headers

1 0

[drupal-devel] [feature] Add timing information to statistics page
by moshe weitzman 11 May '05

11 May '05

Issue status update for http://drupal.org/node/22623 Project: Drupal Version: cvs Component: statistics.module Category: feature requests Priority: normal Assigned to: Anonymous Reported by: Dries Updated by: moshe weitzman Status: patch in the pdf, i think you are swapping 'total' and 'average' column headers moshe weitzman Previous comments: ------------------------------------------------------------------------ May 11, 2005 - 15:05 : Dries Attachment: http://drupal.org/files/issues/timer.patch (8.56 KB) I extended the current timer_start() function in bootstrap.inc and added two new function, timer_read() and timer_stop(). I've used these to profile drupal.org. (A small change will be needed to devel.module.) I've also extended the accesslog-table to keep track of page generation times. The information is shown on the "top pages" page (admin/logs/pages). It shows each page's average page generation time, and the total page generation time. This lets one identify (i) slow pages and (ii) resource heavy pages. This is the most essential and most useful information when tuning your Drupal site. Please review, or I'll commit it as is. ------------------------------------------------------------------------ May 11, 2005 - 15:13 : Dries Attachment: http://drupal.org/files/issues/timer.pdf (22 KB) Screenshot. ------------------------------------------------------------------------ May 11, 2005 - 16:04 : Dries Setting to patch. Take a look at the patch + screenshot please. ------------------------------------------------------------------------ May 11, 2005 - 16:19 : moshe weitzman looks ok ... note that there are some unrelated (i think) variable_set() changes in the patch. ------------------------------------------------------------------------ May 11, 2005 - 16:20 : Amazon It's great to have this level of logging granularity. I am concerned that all the logging would add over head when having multiple crawlers crawling the site during testing. Would it be possible to support batching the log entries and submitting them to the database as batch query at set increments instead of for every page. For example I routinely run several wget crawls for different roles when testing an upgrade. If I ran 5 crawlers and each of 10, 000+ pages were being crawled then I am concerned the performance would be impacted. I understand this isn't the intent of this patch but non intrusive logging is important in generating accurate performance measurements. Thank-you for your consideration. Kieran

1 0

[drupal-devel] [feature] Add timing information to statistics page
by Amazon 11 May '05

11 May '05

Issue status update for http://drupal.org/node/22623 Project: Drupal Version: cvs Component: statistics.module Category: feature requests Priority: normal Assigned to: Anonymous Reported by: Dries Updated by: Amazon Status: patch It's great to have this level of logging granularity. I am concerned that all the logging would add over head when having multiple crawlers crawling the site during testing. Would it be possible to support batching the log entries and submitting them to the database as batch query at set increments instead of for every page. For example I routinely run several wget crawls for different roles when testing an upgrade. If I ran 5 crawlers and each of 10, 000+ pages were being crawled then I am concerned the performance would be impacted. I understand this isn't the intent of this patch but non intrusive logging is important in generating accurate performance measurements. Thank-you for your consideration. Kieran Amazon Previous comments: ------------------------------------------------------------------------ May 11, 2005 - 20:05 : Dries Attachment: http://drupal.org/files/issues/timer.patch (8.56 KB) I extended the current timer_start() function in bootstrap.inc and added two new function, timer_read() and timer_stop(). I've used these to profile drupal.org. (A small change will be needed to devel.module.) I've also extended the accesslog-table to keep track of page generation times. The information is shown on the "top pages" page (admin/logs/pages). It shows each page's average page generation time, and the total page generation time. This lets one identify (i) slow pages and (ii) resource heavy pages. This is the most essential and most useful information when tuning your Drupal site. Please review, or I'll commit it as is. ------------------------------------------------------------------------ May 11, 2005 - 20:13 : Dries Attachment: http://drupal.org/files/issues/timer.pdf (22 KB) Screenshot. ------------------------------------------------------------------------ May 11, 2005 - 21:04 : Dries Setting to patch. Take a look at the patch + screenshot please. ------------------------------------------------------------------------ May 11, 2005 - 21:19 : moshe weitzman looks ok ... note that there are some unrelated (i think) variable_set() changes in the patch.

1 0

[drupal-devel] [feature] Add timing information to statistics page
by moshe weitzman 11 May '05

11 May '05

Issue status update for http://drupal.org/node/22623 Project: Drupal Version: cvs Component: statistics.module Category: feature requests Priority: normal Assigned to: Anonymous Reported by: Dries Updated by: moshe weitzman Status: patch looks ok ... note that there are some unrelated (i think) variable_set() changes in the patch. moshe weitzman Previous comments: ------------------------------------------------------------------------ May 11, 2005 - 15:05 : Dries Attachment: http://drupal.org/files/issues/timer.patch (8.56 KB) I extended the current timer_start() function in bootstrap.inc and added two new function, timer_read() and timer_stop(). I've used these to profile drupal.org. (A small change will be needed to devel.module.) I've also extended the accesslog-table to keep track of page generation times. The information is shown on the "top pages" page (admin/logs/pages). It shows each page's average page generation time, and the total page generation time. This lets one identify (i) slow pages and (ii) resource heavy pages. This is the most essential and most useful information when tuning your Drupal site. Please review, or I'll commit it as is. ------------------------------------------------------------------------ May 11, 2005 - 15:13 : Dries Attachment: http://drupal.org/files/issues/timer.pdf (22 KB) Screenshot. ------------------------------------------------------------------------ May 11, 2005 - 16:04 : Dries Setting to patch. Take a look at the patch + screenshot please.

1 0

[drupal-devel] [feature] Adder timing information to statistics page
by Dries 11 May '05

11 May '05

Issue status update for http://drupal.org/node/22623 Project: Drupal Version: cvs Component: statistics.module Category: feature requests Priority: normal Assigned to: Anonymous Reported by: Dries Updated by: Dries -Status: active +Status: patch Setting to patch. Take a look at the patch + screenshot please. Dries Previous comments: ------------------------------------------------------------------------ May 11, 2005 - 22:05 : Dries Attachment: http://drupal.org/files/issues/timer.patch (8.56 KB) I extended the current timer_start() function in bootstrap.inc and added two new function, timer_read() and timer_stop(). I've used these to profile drupal.org. (A small change will be needed to devel.module.) I've also extended the accesslog-table to keep track of page generation times. The information is shown on the "top pages" page (admin/logs/pages). It shows each page's average page generation time, and the total page generation time. This lets one identify (i) slow pages and (ii) resource heavy pages. This is the most essential and most useful information when tuning your Drupal site. Please review, or I'll commit it as is. ------------------------------------------------------------------------ May 11, 2005 - 22:13 : Dries Attachment: http://drupal.org/files/issues/timer.pdf (22 KB) Screenshot.

1 0

Re: [drupal-devel] Cleaner Directory structure
by K B 11 May '05

11 May '05

> What I am suggesting is a small change like the one at the end of this > email. It will give the opportunity to maintain all or modst of the > scenarios described so far, and will make drupal more packageable by the > distributions, as . The downside is that it will require a central > configuration file ( put in /etc/drupal ;) > > This suggestion should not have any performance implications, as far as > I am aware, apart from the loading of the configuration file, let's be > serious. > > I wouldn't argue with any default directory scheme suggested, I like the > current one myself, as long as it is trivial (read standard and > configurable) for an admin to set up the directory structure they like, > and drupal is packageable without modifications bar config by debian. > > Be flexible if it doesn't hurt you. > > Cheers, Vlado I think your idea has a lot of merit, and provides excellent flexibility. What I am not clear on is, for shared hosting, where would this file go? Also, how does it map into the notion "a directory that does not need to be changed" which I am lobbying for? My goal is to reduce clutter in the parent directory, and provide a drop in upgrade feature for core. I think we can marry the two ideas (mine, and yours) like this: public_html/.htaccess.example public_html/index.php public_html/drupal/ public_html/drupal/drupal.php <==== THIS IS THE NEW FILE public_html/drupal/includes/ public_html/drupal/modules/ public_html/drupal/themes/ public_html/drupal/misc/ public_html/drupal/doc (contains all the .TXT files) public_html/local/ public_html/local/sites public_html/local/sites/default/ public_html/local/sites/default/settings.php.example public_html/local/modules (contrib modules that are shared for all sites - empty) public_html/local/themes (contrib themes that are shared for all sites - empty) In the drupal.php file, we have this: <?php // Directory where drupal core is located $drupal_core = 'drupal'; // Directory where site configurations, and contributed modules and themes are located $drupal_sites = 'local'; ?> conf_init() will be like this: $drupal_conf='drupal/drupal.php'; foreach (array("$sites/$config/$dir/$file", "$sites/$config/$dir/$name/$file", "$core/$dir/$file", "$core/$dir/$name/$file") as $file) { if (file_exists($file)) { $files[$type][$name] = $file; break; } } This achieves everything I wanted for shared hosting, where drop in upgrade is easy, and there is no clutter. Yet, with your added flexibility, distros can change $drupal_conf to anything they like, and/or the contents of the drupal.php file as well.

1 0

[drupal-devel] [feature] Make $node->type a class in the main div of the default node.tpl.php
by factoryjoe 11 May '05

11 May '05

Issue status update for http://drupal.org/node/22487 Project: Drupal Version: cvs Component: theme system Category: feature requests Priority: normal Assigned to: willmoy Reported by: willmoy Updated by: factoryjoe Status: patch This will be in the upcoming versions of SpreadSpread (was SpreadFirefox), Lincoln's Revenge and Democratica. factoryjoe Previous comments: ------------------------------------------------------------------------ May 10, 2005 - 01:36 : willmoy Attachment: http://drupal.org/files/issues/nodetype_theming.patch (716 bytes) This patch would change the main div of, for example, a sticky book node from: <div class="node sticky"> to: <div class="node node-book sticky"> This is to aid theming; motivated by trying to theme forums differently from pages etc. It uses the same convention as node type-specific blocks (e.g. class="block block-book") and it is should be completely backward compatible so long as people do not have very odd tastes in class names. ------------------------------------------------------------------------ May 10, 2005 - 11:30 : adrian You could also just copy node.tpl.php to your theme dir and modify it there to user $node->type, and if you only want to do something for forum nodes, you could copy the node.tpl.php to node-forum.tpl.php PHPTemplate has been moved to core for 4.7, so I will only accept this patch for the 4.6 branch if it is accepted into core. Otherwise your templates will just magically stop working. ------------------------------------------------------------------------ May 10, 2005 - 14:42 : stefan nagtegaal I do think this is nicer than the way of having multiple node.$type.tpl.php files as we have now... ------------------------------------------------------------------------ May 10, 2005 - 14:49 : willmoy Both are useful. This exposes options to CSS that wouldn't otherwise be there, but there are of course PHP things that you can only do in node-whatever.tpl.php. This patch augments current functionality, it doesn't replace it or make it redundant.

1 0

[drupal-devel] Drupal.org visual status
by Kent Livingston 11 May '05

11 May '05

What I feel a *little* less dumb about (but am going to duck anyway) is something I've brought up before and that's the, to me, unsightly overlapping elements on drupal.org home page. As I opened up the page today in IE, or Firefox The 'bright green' download 'block' overlaps and sits on top of the 'skin toned' main introductory block at the top of the page. And the dark blue tabs bunch "down" and under at the right side of the top row covering/layering over the search input field. Yes, if you always use fully expanded web pages it looks fine, but there are legions of people who like to see multiple windows at one time and don't keep all their application windows maximized to full screen. For us the Drupal site looks pretty odd. No, I don't have an answer. Steve and I have gone around a bit on this before but I just don't think it represents the best of what Drupal can do visually. And since my foot is so far into my mouth already I might as well say that the color combinations make me a tiny bit sea-sick. (I'm not quite suicidal enough to say anything about the logo) There have been major improvements for which I applaud Steve and others, but I would like to encourage the 'presentation' contributors to consider what might improve the 'flagship' and take it to the next level. I realize this is somewhat secondary to the back-end, but it is important as it is the visible 'face' of Drupal. I would say the visual presentation on the Drupal site is maybe 12-24 months behind the conservative edge of web site design look and feel. As I get ready to duck the tomatoes, and the "well do something about it, complainer" messages ;-), I think honest feedback that is outside the realm of having the skills to contribute can be seen as a contribution in of itself. Ok, let them fly... -Kent

3 2