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.

The up and coming PHP 5.4 NEWS contains a cryptic entry "Added closure $this support back". This inspired me to write a blog post on closures because we might to want use them in Drupal 8^*. Here is the simplest closure example

In a long and fierce debate with Jen Lampton (mikey_p, HedgeMage and heyrocker was involved some as well) we have arrived to an incredibly important realization: theming newbies apparently don't find simple logic (if, print, function calls) problematic they have problems with data structures!

Most entities you meet in Drupal 7 are pretty complex objects stored in a local database. That's not something the field system expects. The field system, in fact, will never use more than entity_extract_ids to interface with your entities by design. Both that function and the field system will use metadata from hook_entity_info so that can't be skipped. This is how you can interact with the fields system if you just pull some entity data out of thin air (like a web service):

I plan to create a screencast as well but meanwhile, here is a useful guide to the new Relation 1.0 alpha 2. We have relation entities which describe the relation between two or more endpoint entities. Endpoints entities are described by an entity_id, entity_type pair which is stored in a special field called endpoints. This a relation_endpoint type field, you can't create more of this type in the UI nor you can delete the single field of this type from the UI.