The commit log of kohana/kohana on GitHub. I opened it in the summer and counted: a few merges a month, then fewer, then nothing. This year the official development basically stopped. Our projects did not stop working on that day. But the question came to my inbox three times since, so here is the answer. What to do with a working Kohana product depends on which of four situations you are in. ...

Kohana::find_file(). One function, maybe forty lines. If I could keep only one thing from Kohana, this is the one. It looks for every file in order: application/, then modules, then system/. First found wins. Config, views, classes, i18n, everything goes through the same lookup. In practice: a module ships a config file, you put a file with the same name into application/config/, change one key. The module does not know. Nothing under modules/ is touched. ...

Fifty one queries. That is what the SQL panel of the Kohana profiler showed for one catalog page. Fifty posts on the page. Nothing changed in the code. The page took two seconds because there was more data than in spring, and the code was written for spring. $post->author->name in a loop. One query for the list of posts, then one more for the author of every post, inside the foreach. The line looks innocent, and that is the problem: lazy loading hides the price. You write the relation, you go home early, and the bill comes in six months. ...

Request::factory('widgets/stats') inside a controller. A colleague looked at this line last week and asked the question I hear most often about Kohana: you already have a request, why make another one? I keep answering it at the desk. So I will write it down once. Short notes, mostly backend, mostly PHP. This is the first. The answer is composition. Take a dashboard. A stats block, a recent orders block, a notifications block. Each one needs its own data and its own logic. You can put all of it into one action. It works. In a month it is 300 lines and nobody wants to open it. ...