preg_filter() is identical to preg_replace() except it only returns the (possibly transformed) subjects where there was a match. This is most useful with an array as the subject: previously you'd need to use preg_grep and preg_replace with the same regular expression to achieve this. It's obviously much faster to do a single command. Very handy!

The biggest news (literally) is the entity storage patch finally nearing completion -- after yched and me have worked on this a lot, now is carrying the half megabyte monster home. The reason for this size is fields no longer will be shareable between entity types (but they still be shareable between bundles). Meanwhile, berdir is finishing the Entity NG conversion (go berdir!) and moves baseFieldDefinitions from storage to entity classes. The smaller the storage classes the better for us, quite obviously.

Based on a discussion on IRC this is not apparent to everyone so let me write down quick my core workflow:

There is a module (which I will not link) which is a duplicate of another, providing functionality that is absolutely crucial to every high performance Drupal site. Now, aside from the dubious claims it being faster than the original (it has been proven not to be and so now there are only indirect claims of it on the project page), it have proposed to replace the original instead of cooperating and, worst of all, it made a syntax error in a stable release. Stable releases are under the security team umbrella. For me, this situation is not acceptable. When I filed an issue in protest (which, to be fair, did not mention the security angle), the security team leader have said "I think it's fine to ignore this issue". I have no avenue left to protest but to resign from the security team. Once again, it's not really the specific module that is the problem it's just a symptom. We need to tear down the walls on who can create projects as it is clearly visible that they do not help at all and at the same time we need to change the role of the team and make it very clear that most modules are not under the security team umbrella. Discussions have happened about this for years now but I feel the time has run out. I am glad I could help this last eight years.

The very first step is broken here: you fork the repository. At this very moment you are off the main community and noone knows what's going on. You hack but hack alone. Currently one can review the 'entity system' issues in one central place where discussion and code is happening (github separates issues from pull requests). This coherent, single, participatory, inclusive system is missing. We do not want people going off and working separately, making their work visible only when they think it's ready.

My entity logic mover patch got in, slimming down the storage controller classes significantly. This will make it much easier to support them in MongoDB. Two things remained (load and baseFieldDefinitions), load being postponed until the NG conversion is done and the baseFieldDefinitions move architecture foundation just got in. This is progressing remarkably well. At the forthcoming weeklong Dublin code sprint I will move the field_sql_storage module inside DatabaseStorageController ending this weird notion of fields existing somehow separately from entities.

There are a lot of great things happening! Let's first see those that are already in: the config system got back to a saner track by removing the partial import capability and only allowing import of full config trees. This removed manifests which, honestly, I never truly grokked. Also, config import and sync were converted to pluggable services earlier so if someone can figure out how to do partials better then they can do.

There are a number of Drupal 8 issues that simply make me sad. I still didn't stop contributing to Drupal nor I plan to, I just need to accept that we have some disagreements which are not getting resolved. It's frustrating and I am mostly just venting so comments are disabled. (It's frustrating enough that I went over them to tag them.)

Ps. There's a little silver lining: the config import code has been rewritten finally. Still, I will not touch CMI.

Recently a post appeared which stated Drupal became the Scientology of open source and because it appeared in a reply of a few tweets involving me and it contains my name, I need to answer it.

The biggest changes (at least from my end, as usual) since the last update are allowing plugins to have their services injected. It's perhaps not the most beautiful solution ever but it works. Again for plugins, one directory depth have been removed, it's still ridiculous but less so and the PHP-FIG (nudged by our quicksketch, thanks much) is finally moving ahead with creating a new autoloader standard which will make the directory structure a bit saner.