Today I found myself in a complex codebase and my ticket was: this JS on this old page makes the monkey dance, can you make it dance on the new page? Well, my JS knowledge is... limited but I have a really mean right click. So I right clicked and looked around the source Chrome showed me. There was a div with a class slideshow-node-embed-processed.

Perhaps the most important development is the final naming of what was field/field instance in Drupal 7: in Drupal 8 these are configuration entities. The machine names are field_storage_config and field_config. There has been several renames but we have settled on these finally (although the field_config rename is not yet in). It does reflect the most important difference between them: field storage contains everything pertaining to the storage of the field. The things that do not change the storage of it go into the instance.

Or, languages are really hard.

So I was handing over some CSV export functionality to a client who loaded it into Excel as it is without using the import wizard. This resulted in misinterpreted UTF-8 as WIN-1252. I quickly wrote this little function to add a BOM (error handling omitted for brevity):
<?php
function uconv($text) {
$descriptorspec = array(array("pipe", "r"), array("pipe", "w"));
$process = proc_open("/usr/bin/uconv --add-signature", $descriptorspec, $pipes);
fwrite($pipes[0], $text);
fclose($pipes[0]);
$text = stream_get_contents($pipes[1]);

I was given a problem: the (somewhat usual) error message showed up Warning: Invalid argument supplied for foreach() in element_children() (line 6396 of common.inc).. Trying to debug it with the usual print-and-see is entirely and totally hopeless. If you print just $elements from element_children? You get picture. If you try to print the backtrace? It's impossibly big. One hope is printing the backtrace with DEBUG_BACKTRACE_IGNORE_ARGS and then manually opening up every step in the rather big backtrace.

The standard mechanism for backend-aware service overrides is in and these services are already tagged. We have agreed on how to transfer data from one backend to another and my sandbox contains the first getTransferIterator implementation for config with more to follow.

After writing my first Drupal 8 contrib module I have a new appreciation. Let me try to explain. It is certainly possible to write a letter on an empty sheet of paper but achieving tidy results is quite a lot easier if it's a lined sheet. In Drupal 7, the code flow in general is calling a function, getting an array, manipulating the array and passing it to another function. Pretty much anything goes. In Drupal 8, you are handed an object and the object has methods.

There hasn't been an update for some time now; things have quieted down a bit, I am mostly just writing drivers now (and coach people on migrate). MongoDB module caught up with the latest config changes and so the module works again. Migrate bugfixing moves along steadily with more and more people actually trying it and fixing bugs, hurray!

At Szeged, I asked a female Drupal contributor in Hungarian (I'm glad she did not understand) what was up with the coffee maker, because I readily presumed she was staff.
I saw one of the female geek role models at Austin with her baby. I got confused for a second, because apparently I think the übergeek and mother roles can't overlap.
On IRC, I almost said "Wow, that's impressive from a girl.".

With config_devel, when you are editing a migration, you can just enter the name of the file being edited at admin/config/config_devel and on every request the module will check for changes and import the file into the active storage. The other direction works as well: say you are working on a contrib module and have a view. Provide the path of the file (this time in the auto export box) and on every change Drupal will automatically export. Once satisfied, just commit.

We are denormalizing into a field past migration; while usually I freak out writing directly to the field tables in this case it's justified because it's a custom module (never do this in contrib) and also because we are well aware of what does not happen when you do that (pluggable field storage and hooks). With that said, we have a query that roughly looks like this:

INSERT INTO {field_data_field_denorm_data}
(entity_type, bundle, deleted, entity_id, revision_id, language, delta, field_denorm_data_target_id)
SELECT 'user', 'user', 0, field1, field1, 'und', ????????????, field2