August 2006 - Development - lists.drupal.org

Re: [development] CVS HEAD, code freeze, zeitgeist
by Peter Wolanin 18 Aug '06

18 Aug '06

Dries, I've been trying to help on improvment of the book module and caching (among others): http://drupal.org/node/65319 http://drupal.org/node/72617 http://drupal.org/node/76040 and trying to review some others (like the trashbin): http://drupal.org/node/35422 From: Dries Buytaert <dries.buytaert(a)gmail.com> Subject: Re: [development] CVS HEAD, code freeze, zeitgeist Hi Peter, On 18 Aug 2006, at 15:55, Peter Wolanin wrote: > Regarding the development cycle and Sept 1 code freeze- in trying to > make some contributions myself, I'm left with the feeling that the > pace is currently a little too fast. What kind of contributions do you want to make? Contributions to Drupal core, or to modules in the contributions repository? -- Dries Buytaert :: http://www.buytaert.net/

1 0

Summary of 5 Drupal administrator interviews
by Kieran Lal 18 Aug '06

18 Aug '06

Hello, I conducted 5 interviews today and began the process of summarizing the findings leading to a Drupal administration survey. My hope is to do 4 more interviews tomorrow and collect interview notes from Dries and Steven Peck. I'll then put out a draft survey for comments and deploy on the home page of Drupal.org ASAP. Summary: Usage of Drupal Daily for 30-60 minutes of website management Daily for several hours in site development and deployment Motivations for using Drupal Speed of feature and requirements deployment is critical to choosing Drupal Quality of people, their contributions, helpfulness, and community building domain knowledge is critical to choosing Drupal Drupal website end users benefit from fast feature deployment and Drupal feature innovation Tasks-Drupal software Logging to identify the state of the web site as well as events that indicate upcoming website issues are critical. Managing users, content, and spam are top activities for administrators. Better contextual interfaces are need to manage this. e.g. Banning, un-publishing should be beside username or content not in administer >> somewhere Discovery of administration settings is hard. Grouping settings into situational use is important. Situations include: site building, new feature testing and deployment, and ongoing maintenance User interfaces for large scale management of Drupal (blocks, menus, content, categories, users) do not scale adequately. e.g. interface assume individual changes and not bulk changes of hundreds of items. Tasks-Drupal processes Testing features and getting feedback from site users is an important activity. e.g. provide testing role with feedback block for that role Process of discovering features, downloading, installing, configuring, testing, filing issues, working with developers, evaluating, and abandoning broken modules is a major cost associated with administering Drupal Integrating features(module X and module Y) produces errors and makes theming hard. Despite difficulties it is a net positive. Upgrading and versioning Drupal and the ability to make informed decisions about this process is currently inadequate. Here is table collecting responses from the interviews: http:// drupal.org/node/77193 Interview 1: http://groups.drupal.org/node/1136 Interview 2: http://groups.drupal.org/node/1135 Interview 3: http://groups.drupal.org/node/1133 Interview 4: http://groups.drupal.org/node/1137 Interview 5: http://groups.drupal.org/node/1134 Cheers, Kieran CivicSpace

2 1

Re: [development] CVS HEAD, code freeze, zeitgeist
by Peter Wolanin 18 Aug '06

18 Aug '06

Regarding the development cycle and Sept 1 code freeze- in trying to make some contributions myself, I'm left with the feeling that the pace is currently a little too fast. Rather than making Sept. 1 a code freeze, would it be possible to make it a feature freeze? i.e. define a list of features where some of the code may not yet be RTBC on Sept 1, but which must/will be included in the next release? I think Dries had a top 10 list in a previous thread that would be a starting pont for this. -Peter

2 1

Missing ?> in 4.7.x Files
by inkfree press 18 Aug '06

18 Aug '06

I am trying to determine if something is happening to unpacked zip files OMM, or if there is something else going on. After experiencing some odd errors, it came to my attention that certain files in the unzipped 4.7.2 and 4.7.3 releases are missing a final ending "?>" PHP closing tag. For example, 'index.php' looks exactly like this (4.7.3): =======<code> <?php // $Id: index.php,v 1.90 2006/01/27 18:51:51 dries Exp $ /** * @file * The PHP page that serves all page requests on a Drupal installation. * * The routines here dispatch control to the appropriate handler, which then * prints the appropriate page. */ require_once './includes/bootstrap.inc'; drupal_bootstrap(DRUPAL_BOOTSTRAP_FULL); $return = menu_execute_active_handler(); switch ($return) { case MENU_NOT_FOUND: drupal_not_found(); break; case MENU_ACCESS_DENIED: drupal_access_denied(); break; case MENU_SITE_OFFLINE: drupal_site_offline(); break; default: // Print any value (including an empty string) except NULL or undefined: if (isset($return)) { print theme('page', $return); } break; } drupal_page_footer(); =======</code> That document ends (OMM) with the final code line at line 34, then is followed by two blank lines. The final line is numbered 36, that is, but 35 and 36 are line feeds/new lines only. [Note the missing ?> after that final function call.] Is this something happening during MY unzip, or is this also true for others? I really find this interesting, and will clearly explore any issues which might be affecting my machine. Thanks for any insight. -- inkfree P.S. 'My machine' = Mac OS X.3.9 (Panther) and I've been unpacking and testing Drupal here since before version 4.6, with no problems at all.

3 3

EuroOSCON: discount
by Dries Buytaert 18 Aug '06

18 Aug '06

Hello world, if someone still wants to attend EuroOSCON, let me know. I just received a registration code that offers a 35% discount. -- Dries Buytaert :: http://www.buytaert.net/

1 0

announce: drupaldigest.com
by Moshe Weitzman 18 Aug '06

18 Aug '06

I'm happy to announce that http://drupaldigest.com is now available. This site provides filtered rss feeds of drupal mailing lists. If you are too busy to read lots of list mail, or only peripherally interested in a list, then consider signing up for one of these feeds. An editor identifies the best posts from each list and adds them to the RSS feed. If you are curious how this site works, see http://drupaldigest.com/about. If you want to become an editor for a list that is not yet available (themes, consulting, translations, infrastructure, ...), please contact me. Feel free to publicize this announcement on your blogs and elsewhere. -moshe

1 0

For review/input: HOWTO: Benchmark Drupal code
by Angela Byron 18 Aug '06

18 Aug '06

(Yes, technically this is a documentation thing, but it needs developer input and I know a lot of you aren't on the docs list) I've put up a kind of 'skeleton' handbook page on how to benchmark Drupal code here: http://drupal.org/node/79237 This whole benchmarking thing was kind of an arcane voodoo art thing to me until recently (and actually to a large extent still is ;)), but I noticed increasingly coming across patches that basically say "Let's see some benchmarks before we even think about committing this to core." I figured there might be other people in the same boat as me, so thought it would be good to document how this was done so we're not reliant on only a handful of people (Dries, killes, etc.) to do it. Most of the stuff I've documented is in the area of setting up a performance testing environment.. I think that part's pretty solid, but I'd really appreciate any additional feedback people have on: - "Tools of the trade" - Tricks that are helpful - How to interpret results - (maybe?) How to take raw ab output and turn it into pretty graphs like on Dries's site - other stuff Thanks in advance for any help! -Angie

1 0

RE: [development] Fixing themes and regions
by Metzler, David 17 Aug '06

17 Aug '06

My short answer (2 cents) is yes, but I wonder if there might be another way? I wonder if there could be an approach where the defaults would only be overridden if an theme admin set that option for a specific theme, kind of like the way "global settings" was originally implemented in themes, but for block/theme configuration? Further explanation of instability problems: Ambiguity is introduced for sites in which users get to pick a theme. When the user picks a theme and submits, the options about which blocks are enabled or hidden or visible could change, but they wouldn't have those options until after they'd picked a new theme. Cases where the theme overrides the allowable regions can also a point of instability but do not have block administration privileges. I've had to remove overriding sections of contributed themes, and the add the unsupported regions "somewhere" in order to make it so that a user can "select a theme" without all the blocks disappearing. Hope that helps for the dicussion... -----Original Message----- From: development-bounces(a)drupal.org [mailto:development-bounces@drupal.org] On Behalf Of Nedjo Rogers Sent: Thursday, August 17, 2006 12:42 PM To: development(a)drupal.org Subject: [development] Fixing themes and regions The region handling we introduced for 4.7 (and that I mostly wrote) is a step forward but produced confusion and instability in multi-theme sites. It's cumbersome to have to configure things like enabled status separately for each theme. As a 4.7 workaround I wrote a helper module, http://drupal.org/project/issues/blockregion. I know that there's work ongoing to improve theme handling of regions. But I'm behind on the status of this work. Is any of it for 4.8/5.0? If not, I'd like to consider the following approach: 1. Drop the ability for each theme to define more than the region of a block. 2. Pull the theme-block configuration into a separate table, e.g., block_theme, with fields module, delta, theme, region 3. Limit the UI configuration to region only for non-default themes. Is this needed/a good idea?

1 0

Drupal performance
by Dries Buytaert 17 Aug '06

17 Aug '06

Hello world, recently I did some performance analysis of Drupal and compared it to Joomla. http://buytaert.net/drupal-vs-joomla-performance Unfortunately, Drupal is quite slow when it comes to generating non- cached pages. It would be great if we could focus some more on the performance of non-cached pages. Why? Because in practice, it is often a _lot_ more important than the performance of cached pages. I know there are some patches in the queue, and I know we talked about this a lot in the past. I'll review, test and benchmark some of these patches ASAP. There are also a number of ideas that haven't been implemented/tested yet. I hope that you will do the same, and that you continue to think (out of the box) with regard to Drupal's performance. Thanks, -- Dries Buytaert :: http://www.buytaert.net/

9 9

FLOSS 12: Rasmus Lerdorf
by Dries Buytaert 17 Aug '06

17 Aug '06

Hi guys, if you have some time to kill, make sure to listen to this podcast: http://www.twit.tv/floss12. Talks about the history of PHP, performance and scalability, Drupal, PHP's new security model, etc. -- Dries Buytaert :: http://www.buytaert.net/

5 4