I was going to post this as a response to #2208429-145 on drupal.org, but then figured this is waaaay too long. And too full of myself, possibly.
I then decided to instead post a shorter comment, and put the rest here.
Since I am too lazy to write "real" blog posts, maybe my blog is still good enough as a "dumping ground" for stuff like this.


Recently, Drupal 7 had quite a massive and unique SQL injection vulnerability.
Luckily, Drupal also has an awesome security team, and a security mailinglist, where they announced the vulnerability and how to fix it.

I wanted to write a module with a views plugin.
This is one single class. Do we need PSR-4 for that? (*)

Looking back, I can say: The question was misleading.
No, I don't necessarily need PSR-4 for one single class. But once I had it in place, I quickly noticed how I could split big parts of the logic out of the views plugin, into a separate class. Quite a healthy thing to do.
Without PSR-4, I would have hesitated to introduce another class.


Drupal's "theme" concept introduces unhealthy dependencies and hinders modularity. Use theme-agnostic front-end components instead, and let them live outside the theme.

(Disclaimer: Yes, Drupal is not the only system with "themes". Forgive the clickbait headline.)

Someone at the Acquia booth talked me into their certification program. Here is how it went.


The DOM is a hierarchical structure. And yet we are generating HTML in a linear fashion. We can do better!

Cellbrush table generator

Cellbrush is (yet another) PHP library to generate HTML tables.
It does support colspan and rowspan.

What really makes it special is that table cells are addressed by string keys, and empty cells are filled automatically. This means, you can add cells in any order, and you don't need to babysit the table's structural integrity! This allows for a more semantical work flow.


xautoload never had a database cache. But now it has, thanks to O(log n).

All (*) the procedural pasta salad of Drupal 7 core, turned into services with dependency injection because we can?
(and because PHPUnit, and because ..)
(*) exaggerating.

No, this is not Drupal 8. It is just a testing ground for xautoload.

A one-off service container that is simpler than Pimple.

It will not be very flexible or reusable, it will just do the job.
And your IDE will love it!