Ok, this caused a fair amount of hair pulling at my end, and I couldn’t find anyone else who had blogged about it… so..

I recently rolled Known’s Symfony components up from using the 2.x version of PDOSessionHandler to 4.x. I had tried this before, but I thought I’d have a fresh attempt at it, but ran into the same weird problems.

Sometimes things would work, but other times it wouldn’t, and the CI tests would consistently fail with a PDOException "There is no active transaction"

Symfony docs, and no amount of googling, got me nowhere. Eventually, reading through the code comments, I hit on the answer. So, I’m writing it here to make things clearer, and with hopes that someone else in a similar position doesn’t have such a frustrating time of it.

Turns out that PDOSessionHandler has switched to using transactions by default. Fine, but it turns out that this can cause some interesting interactions if you share the same database connection as used by the application (which was what we were previously doing, and was the standard way of doing things circa 2.x).

Your options then are either to create a second connection to the database, just for the session (which is not great for our purposes, as it would require two database connections per page load), or turn off transactions.

To do this, pass as an option:

'lock_mode' => PdoSessionHandler::LOCK_ADVISORY

Hope you find this helpful!

Symfony Twig is a PHP templating engine, which has pretty much become the standard way that PHP applications do templating. I’ve used it in other projects, and find it pretty cool.

Known uses its own PHP templating language… or rather, it uses PHP. But, I thought it would be useful if Known could support both.

So, in the latest build, as well as .tpl.php Bonita template files, you can also create .html.twig files. These work in pretty much the same way, with the same hierarchy, but provide a more “standard” way of doing things.

I don’t imagine Bonita going anywhere any time soon, but I will probably be moving more and more stuff to twig going forward.

A number of folk have been starting to see some more spam comments appearing in their logged out comments section, posted by bots.

I’ve already written an Akismet plugin, which has helped with some of it, and Known core has also been extended with some countermeasures. However, I have wanted to see if I could do some more.

When I was wearing one of my other hats the other day, I had the opportunity to play with the new Recaptcha 3 code, and I thought I’d bring it to Known.

Recaptcha 3 takes a new approach to detecting bots. Rather than getting a popup and getting you to click on pictures (which is very very annoying, and hard for those with accessibility issues), Recaptcha 3 does some arcane magicks behind the scenes to determine who’s bot or not, and then gives you a score indicating the likelihood that you’re dealing with a human. 1.0 for high likelihood of a meat sack, 0.0 for a bot, and then any value in between.

Much like with spam detectors like Spam Assassin, you can then set your own threshold values and do this on a page by page basis.

Crucially, you’re never going to get a popup. Thank the Gods.

Anyway, I’ve built this out as a plugin. Out of the box, you’ll get protection for login, registration, and public comments, but you can extend it to protect your own custom forms without too much trouble.

Have a play!

» Visit the project on Github...