core
Drupal 7 core forum module - plan of attack
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.
Generalizing node context
Been sitting on this idea for a while: curious to see what people think.
In a nutshell, the idea is to combine and generalize the various flags for a node that are available in node.tpl.php, and open them up to modules.
For example, instead of the $is_front, $page, $sticky, and $teaser booleans, you'd have an array with entries present if the flag is true. Something like this, for example:
$context = array(
'teaser' => array(),
'sticky' => array(),
'page' => array(),
);Core would take care of shoving those keys in; other modules would given a chance to add their own to a node.
That's the plan. Here's why I think it's cool:
Input formats. A different point of view
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 :)
State of the issue queue
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.
Redefine what's considered a core module
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.
Drupal memory consumption by core and modules
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.
Javascript patches need reviews!
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:
Call for work on additional core install profile(s) for Drupal 6
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.
Core themes
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?
themefunctions calling themefunctions calling theme functions (calling Drupal apis) calling theme functions
... 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.
