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.

By default AJAX submits to system/ajax and retrieves the form from cache. So if your form depends something from the page it originally appeared on it then you need to store that in $form_state, the whole of $form_state is cached alongside of the form (only a few internal keys are not).

What I wanted, stupid me, change a select box, get my node form to rebuild on an "AJAX submit" and display some changed elements. Well, AJAX does not fire form level submit handlers (this is supposedly a good thing). But, the form only rebuilds if the "rebuild" flag gets set ($form_state['rebuild']) by a submit handler and a submit handler only -- which are not fired. Opsie! While a custom form surely can do something in #process, #after_build etc a node form really wants to be rebuilt. Seems like a stalemate.

The Drupal community helped me to get a Panasonic CF-Y5. I no longer need it so I am planning on passing it on. The tech might be a bit dated but still, it's a capable, very lightweight (1.5kg) machine with 2.5GB of RAM, a dual core first generation Intel Core Duo L2400 CPU and a 60GB HDD. The 14" screen is 1400 x 1050. I have two batteries for it, one original, one OEM. Both last couple hours, I only used the machine recently on planes so I only know the without wifi capability: the original does about 4 hrs. The bottom of the laptops is full of scratches the rest is quite good (well, it's a business rugged Panasonic so it's hardly a surprise). Drop me a line if you are a Drupal contributor and need a laptop.

Seems the community is overly happy with the git migration and it's right to be. But I would like to quietly remind everyone one part of our success is us being centralized. One part the git migration is beneficial to this because all those projects that went off to github can return home. On another part all these "sandboxes" have a danger of everyone going off into their own little corner. Oh yes, our long time core contributors will still post patches and just play nice but ... maybe not.

If you used bzr/cvs/svn checkouts and want something similar then in the repository root do:

After this (on at least on Linux and Mac OS X)

1. Contents will be pushed after every commit
2. new branches will rebase after every pull.
3. The only existing branch (master but can be something else with for example git clone --branch 6.x-1.x use the instruction on the Git instructions page of your project for this step) will rebase after every pull.

It does not abort commits if the local repo is behind remote, however. I would love to see tips on how to do that.