we decided to release a quick patch release today. There was an issue with the writer field that could lead to missing content in writer fields when the slug changed or the page has been moved. This is now fixed in 4.6.1: https://github.com/getkirby/kirby/releases/tag/4.6.1
We also decided to include a small patch from @rasteiner which makes Kirby theoretically compatible with FrankenPHP. (see Roman’s explanation below for more context)
The idea of FrankenPHP would be to have a persisting process that handles many incoming requests (via a “worker” script), theoretically making it faster than starting from scratch each time (kinda like Swoole, I guess).
This isn’t the case now, and actually running Kirby via FrankenPHP seems to be about 100% slower than simple fpm.
I’ve just fixed a compatibility issue that made the kirby panel incompatible with the “classic 1 process each request” mode.
Thanks for the clarification. I’ve never worked with FrankenPHP before and just assumed from the Github issue that this is the only roadblock. I’ve updated the post.
Unfortunately not, I haven’t tinkered with it much however. Maybe I configured it wrong and OPCache wasn’t working correctly. But I guess it’s also that FPM after about 15 years of optimizations, is just really fast. So even matching that performance (without an architectural advantage like having a worker script to persistently keep a cache of the content in memory) would be quite an achievement. Doing so from “outside the php core” would be even more.
My main point however was that the main benefit (imho) of FrankenPHP (worker scripts), wasn’t implemented, and I don’t know if it could be (Kirby afaik relies on “forgetting” the site content between requests).
I had also only tried out v1.4.2 (the latest at the time), and currently they’re at 1.9.1, so mabe the situation has changed.
Try it and see if it has benefits for you. Maybe the other features of FrankenPHP are worth it.