Matt Brown contacted me a few months ago, suggesting that I should consider cleaning up the design and content of Xdebug's website. He spend countless hours both redoing my atrocious (and old!) code that powers the website, and creating a new design for it. During November we put this new design online, and I upgraded the server to run PHP 7.4 too. There are still a few rough edges, and there are a few thins I still want to improve, but I believe that the new design (and code!) are much cleaner. Thanks Matt!

I only spent a little time on Xdebug 3 this month, mostly due to travel to speak at conferences. I did finished the modularizing of the Xdebug code base, and now have moved on to cleaning code up and refactoring it even more to continue to make it more maintainable.

Beyond that, I have started to remove a few things from Xdebug as well. I removed the aggregated profiler feature, which was never documented, and prepared an uncommitted patch to remove the xdebug.remote_handler setting. This setting could only ever have one value (dbgp), and it seems very unlikely that in the future Xdebug will support other debugging protocols. The underlying code for being able to have more protocols continues to exist. This is mainly because it enforces better design and less coupling between the different parts of Xdebug.

I was right to think last month that it would be likely to have to make a bug fix release. A user commented on Twitter that the code coverage functionality was drastically slower. In Xdebug 2.8 I changed how the coverage functionality remembers which classes and their methods it had already analysed. In 2.7 and earlier, it sets a specific flag on the class entry, but that was always a hack, which stopped working (again) with PHP 7.4. Instead of using that flag, I now use a hash table to do so.

However, I had inadvertently negated the check, so instead of only analysing classes and their methods on the first visit, Xdebug ended up analysing it every single time. The fix for this was therefore small (and embarrassing).

During the testing of this new "fix", I noticed that code coverage was still a lot slower than in Xdebug 2.7.2, so I did some more research to improve this. Instead of allocating memory to create the hash key, I use stack memory instead.

For Xdebug 3 I have a few further ideas to speed up code coverage.

The bug fix for the performance degradation is the only ticket that made it into Xdebug 2.8.1.

Update: Xdebug 2.8.1 was released on December 2nd (so not actually in November).

I have had further, but minimal, interest for the Business Supporter Scheme that I launched in September.

This month's new supporter is e3N GmbH. Thanks!

If you, or your company, would also like to support Xdebug, head over to the support page!

Besides business support, I also maintain a Patreon page and a profile on GitHub sponsors.

I have continued with the PHP Internals News podcast. In this weekly podcast, I discuss in 15-30 minutes, proposed new features to the PHP language with fellow PHP internals developers. It is available on Spotify and iTunes, and through an RSS Feed. Let me know if you are a listener! The podcast will be on hiatus until early next year.