We have written some very frustrated blog posts. Time to reflect on them and outline some causes and plans to move forward.

1. Why are we so frustrated?

There have been a small number of people consistently fighting the major/critical bug queue for a long time. We got Drupal 7 released (through patching and reviewing some 8000 issues) but after that we needed to continue the bug fighting and this really got on people's nerves. For example the upgrade path has been critically broken for two years without a break.

First this is not a personal critique of anyone. These are just some of the things that seem hopeless right now

1. There is no place to have a meaningful architecture discussion which core contributors frequent. It was the developer mailing list some time ago.
2. If an issue is not a relatively straightforward bugfix, it has little chance of getting in. Sure, Dries has two kids and two companies and I can understand that -- this is not a critique of Dries. He became a bottleneck none the less.

Right now I can't feel writing anything new major -- however, one of the reasons issues get stuck because it can get tricky to write tests for them. So if your issue gets stuck in the CNW -- Needs tests state, give me a shout.

This might be an old hat to those who are used to creating Views in code, but for me this is a nice new trick. So first create a view in the UI, export it and then cut it down mercilessly. There's extremely little necessary to get a View up and running if you dont care about the display and just want the raw results. First you need

Then a field:

<?php
$handler->display->display_options['fields']['nid']['id'] = 'nid';
$handler->display->display_options['fields']['nid']['table'] = 'node';

The last few days I wrote modulate. This Drupal 6 project has two important parts: a drush script copying various PHP snippets from the database into modulate.inc and modulate.module firing the copies and stopping eval from firing. The ultimate goal is that production could run with the php.ini setting disable_functions=eval. Right now, modulate works with custom block content, block visibility, node bodies, Views 3.x areas (header, footer, empty), default arguments and argument validators. Future plans include CCK textfields, custom panes, the Views customfield module and maybe even Rules (I could use help with that one) and of course a D7 port (help is welcome on that front as well -- it should be very easy). Oh and tests. Please write me tests :)

I took a D7 site as a small side job the last few weeks mostly to learn Views and to get a chance to write a series of blogposts about how to create interesting things with D7 and Views. This is the first but not the last by far. So we needed a portfolio/username view. This is tricky -- you don't want a User: name, instead you need to add a User: uid contextual filter (argument in D6), specify a User validator and pick Only allow string usernames.

This might be boring (and might be better at chxramblings than here) but oh well. I will talk about some things that I perceive as I live the typical (?) geek, introvert life and the consequences for usability.

If you are writing a stream wrapper for Drupal 7 be mindful of two things:

1. If your code throws a notice then up to and including 5.3.5 extremely weird bugs exist that completely break your script.
2. When reading the whole file (for example: file_get_contents), as long as stream_read returns non-empty strings, the return value of stream_eof is ignored.

.

Unless you are architecting core or interested in how that particular sausage is made, please leave in peace and don't hack core.

People have been hollering for a WYSIWYG editor in core for a decade now or so. I have a vision for a limited but actually implementable version of this: the HTML5 Aloha editor in a field widget and in a text field formatter too for in place editing. In place editing is practically impossible in the generic case in Drupal as it's almost impossible to figure out what the raw version of the text is -- but for a text field, we actually have a grip. Anyone wanting to implement a node-based (we do not have entity_save) version of this for Drupal 7 can find me for mentoring the field API parts.