The entity config query is in and the aggregation query system is ready, and it's surprising how little new code was necessary for it -- mostly a little refactor of the existing SQL implementation to make it more reusable and of course a lot of tests -- written with the help of dawehner, thanks! There are a few big issues left: split the entity controller into a CRUD controller and the real controller. Once users become EntityNG, roles need to use the existing entity reference item. Same for taxonomy terms and their hierarchy.

Installing / importing new configuration no longer writes directly the config storage but uses the full Config object which fires events on write/delete. This allowed me to start on writing a config entity query class which subscribed these events and denormalized data suitable for queries. catch then voted this one down, saying it's premature optimization. So a simpler implementation has been submitted which loads all configuration entities of a certain kind (like all Views) and then filters/sorts/etc.

In Drupal 7 one could store every random thing not having its own table with variable_set and retrieved it with variable_get and life was simple. There was the $conf variable in settings.php which allowed an easy override. This worked well... until you wanted to copy variables from one server to the other. Or translate them. In Drupal 8, most variables have moved to config() and are still overrideable by $conf. There are a few exceptions.

Most importantly: we added static caching to the configuration management system. This paves the way of further speedup by utilizing cache_get_multiple instead of loading each object one by one. While Drupal always had the capability to override certain variables in settings.php this is now much nicer and even has its own little API, settings()->get(). The separation of these settings necessary for bootstrap versus the CMI overrides was badly needed. Also, the new Entity Query system now has relationship support (that has been a frequent request).

Almost exactly a year ago I wrote about automating git pull from github. I found myself in an environment where a) I wanted to do this b) PHP had been set up so that git pull didn't work. inotifytools to the rescue. First, write a password-like filename (see the old post) PHP script like this:

I have changed course and speed seemingly because now we are so beyond tresholds that feature patches can't get in. So we are in bugfix mode and I have chosen performance ones because those will help in a lot of ways: it will kill a lot of majors and criticals and also speed up testing which helps development overall. Also, the EntityQuery relationship patch relies on converting everything to the new Entity API and that can't happen if it's slow.

Finally the kernel work is complete: right after settings.php is read, the compiled service container is read and used and there is no other service container being used (while I worked a lot on the early part the previous weeks, this week was mostly the One Container To Rule Them All patch). This means MongoBundle can override everything in the service container easily.

Another week, another kernel patch. This one moves the kernel initialization to very, very early in the bootstrap process, just after settings.php is read. So, the MongoBundle can override everything easily. Great! There's a patch in the queue which I will turn my attention to once this is in which puts the database service in the kernel. More on this a little later.

The new DrupalKernel patch is ready. This will unify the bootstrap and the "real" service container and compile them to disk. Very important for us. Also, I had a rift with another developer for too long but in this issue we finally managed (although it's visible we both struggled) to work together and get to an agreement. I am very hopeful this trend continues.

So Views and Twig are both in Drupal 8 alongside with a configuration import and an entity translation UI. Big, big progress in general. On my end, EFQ v2 has been committed. Now I am doing a number of things in parallel: one, I am rewriting the batch API and have buy in from Crell, bojanz and yched (and I think berdir is OK with it too) so I expect that to get in once it's more completed. We have decided on not supporting "call me again" jobs, just clean, explicit job creation. A new queue operation seems necessarily -- which is move to the end of the queue.