Improvements to core
We are trying to improve core. We need more opinions on ideas and how to achieve them, not only ideas.
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.
Add context for check_markup()
There's one big problem with the current development of Inline API: Filters do not know what "type of text" they are acting on. For example, the "old" Inline module allowed to embed images/files in a node's content, which are attached to the same node. Because filters don't know what they are doing, Inline needed to run via hook_nodeapi() in the past.
In Inline API, I coded around this limitation, but it's still ugly. So I went ahead and checked, how many times check_markup() is actually invoked in Drupal core. Here's the stunning result:
<?php
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:
More defaults in the default install profile
I just opened up two issues:
The idea is to get more dummy content into the default profile, whilst at the same time provide a stripped down profile for people who don't need it. The question is, what else could we put in the default profile if we're able to bloat it a little?
Enable more modules? Which ones?
Dummy content in page nodes and dummy primary links pointing to them?
Dummy article posted to the front page?
RFC: Installation profiles as modules
In Drupal 7, Installation profiles should become modules.
Most of the work done now will be done in hook_enable.
The benefits:
- Profiles get to implement hooks
- To build a profile, you don't need to learn a whole new API
- Multiple profiles can be enabled at once. (Imagine a site for a project - you could enable the wiki profile, blog profile, and project profile)
- Profiles can be disabled
- Profiles can have updates
- Profiles can be monitored w/ update.module
Add Display Name field(s) to core in addition to Username
Add Display Name field(s) to core in addition to Username is a D7 feature request. This document assists advocators to bring clarity and structure to the proposal and formulate design requirements to pass to core developers. So, add to this page.
sun's vision for handling embedded/inline content and Wysiwyg in Drupal
.
.
As some of you know, I've recently taken over maintenance of Inline and Image Assist, and initiated the Wysiwyg project. That was not only caused by personal interest, but also to take the necessary steps to realize the long awaited Inline API. You might ask yourself, what those three modules have in common or to do with each other at all: They deal with user input, allow to embed complex contents into a content, and provide an interactive GUI for that. If you already had the chance to work with them, you already know that there is a rather hidden
, non-obvious hard-dependency between them.
Although I'd really like to discuss both topics (Inline and Wysiwyg support) separately, the gained experience on these topics enforces us to discuss them concurrently. The following mockup hopefully explains why: (see attachment to view in full size)
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 :)
Sessions on "Community: Getting Involved in Core" Wanted For Drupalcon 2008
My name is Matthew Pare and I'm a Co-Chair for the "Community and Core" track for Drupalcon Boston 2008. Over the last couple of weeks we have been planning and brainstorming to make Drupalcon Boston 2008 the best Drupalcon to date! One of our recommended track session topics is "Community: Role of the Contributor" and since your viewing this post on the Improvements to core group I thought you would be excellent candidates for submitting sessions on the topic.
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.
