core

Drupal's core forum module is much maligned. Some of this is unjustified - people expecting it to replace standalone solutions by itself and ignoring the nature of Drupal's modular framework. However, it also has some limitations which are a result of its age and require many workarounds for large community sites.

Many of the forum module's limitations are down to its dependency on the taxonomy module (making it hard to integrate with organic groups etc.) and on comment.module, which is itself in need of a rewrite.

So we're proposing a ground up rewrite of forum.module using nodes.

Drupal is formatting the user input by applying a set of customized filters before the content is send to visitor’s browser. In other words the user input is stored untouched in the database (except the SQL injection filtering) and then the filter module is performing code cleanup and formatting at the HTML output. In fact the input formats are... output formats :)

The past two-three weeks I've spent a lot of time in the Drupal 6 issue queue. This involved a mixture of reviewing patches I really wanted to see get into Drupal 6, writing or re-rolling some small patches for small bugs and typos, and trying to clear the issue queue as much as I could down to a manageable size. I commented on something like 160 issues in seven days, and read through many more.

So Drupal 6 has been the first release cycle I've been involved with on any level, did a few reviews and submitted some very small patches, and followed a lot more as they went in or didn't. The overriding feeling I've got from it is that the division in core between api and cms-type modules is causing problems that are increasingly hard to deal with.

I create a 5.2 and 6.x patch for measuring how much memory a module takes, and also how much the whole Drupal page load takes.

The results are published here: Measuring memory consumption by Drupal bootstrap and modules.

Short version: in Drupal 6, modules are better off than in 5.2, but the bootstrap is a tad larger.

If anyone is interested in replicating the results with more realistic install profiles, please do so and publish your results/findings/recommendations.

With the announcement today of another four weeks before Drupal 6 freeze, we have another chance to get some critically needed Javascript patches into Drupal core.

Very few Javascript patches go through, mostly for lack of in-depth reviews. Please, everyone on this list, take your turn in reviewing Javascript patches! Better yet, wade in and help make improvements to the patches.

Here's a link to Javascript issues needing review:

http://drupal.org/project/issues/drupal?components=javascript&states=8%2...

A few highlights:

Hi all -- hope you noticed that Dries recent call for Drupal 6 usability additions that he specifically called out an install profile.

I refactored the core profiles wiki pageto focus on an additional Quickstart profile. Please review, edit the wiki, and add your own suggestions.

5.x got brand new theme, which is great and Garland is great. Should 6.x include more nice themes in core? There are appearing some very popular ones, such as Bluebreeze. I can imagine Bluebreeze enhanced with color module, which is very good base for some "wiki-like" website. Opinions to more core themes / bluebreeze in core?

... and so on.

We currently have a very fuzzy "tree" that builds our site. I doubt anyone has ever traced the route a string takes from within some Drupal-module 'till its printed.

Some theme functions call other theme functions, whom call other theme functions. Sometimes inbetween you find that Drupal APIs are called.

theme_some_hierarchy() {
  $hierarchy = build_hierarchy()
  foreach ($hierarchy as $subtree) {
    theme('hierarchy_part', $hierarchy, $subtree);
  }
}

Freely crafted after our menu building systems, and just an example.

Recently Dries said he disliked theme functions calling theme functions. This is done all over the place. Maybe we need to look at a solution for this? Something to either get a very consistent page building mechanism (brickslate is an idea to do this after the way JS builds the DOM) . Maybe we need to only create a conceptual guideline. And maybe we need not worry at all and continue trialling-erroring our way to our Perfect Designs.

http://drupal.org/node/62120

Please review this proposal and comment, it's not to late to get students to write up a proposal.