Dev Log - Week 1: Laying the Foundations

This week I started a major refactoring effort across my three WHMCS modules: Billing Extension, Commission Manager and Mercury.

At the moment, I'm also considering the possibility of merging all three into a single, unified product, simply called Katamaze. This is still just an idea, not a final decision, but it's a direction I'm seriously exploring. The concept is simple: instead of choosing which module to buy, customers would have one complete solution that includes invoicing (Billing Extension), affiliate commission management (Commission Manager) and content publishing (Mercury). Of course, anyone could still use only the parts they need.

Because of this huge refactoring, development of new features on the current modules is suspended. It wouldn't make sense to keep expanding the old codebase while I'm rebuilding the foundations of all three modules at once.

A bit of context. Much of the code I'm rewriting dates back to 2014. At that time, WHMCS didn't provide many of the tools developers can rely on today: no autoloaders, no modern class system, no proper multilingual handling. I had to create my own framework from scratch - autoloaders, language system, database layers - everything.

That worked for years, but it also created technical debt. While WHMCS gradually introduced these features in versions 6, 7 and 8, my modules were already tied to the custom ecosystem I had built. I wasn't against WHMCS improvements, I simply couldn't use them without breaking my software.

Now, for the first time, I can finally take full advantage of the modern standards WHMCS offers and leave behind the custom framework I carried for so long.

Another major source of technical debt was my long-standing choice to support too many exceptions. To give you an idea: while WHMCS 9 is about to be released, my modules still support versions 5, 6, 7 and 8. That's not just outdated, it's unsustainable.

I also spent years implementing workarounds for edge cases caused by custom templates or third-party modules (often written in ways that assume they're the only module in a client's WHMCS). This has been a huge drain of time and energy and ultimately benefits only a handful of setups at the cost of everyone else.

From now on, I'm aligning with what every other developer in this ecosystem already does:

• I will only support WHMCS versions that are actively supported by WHMCS itself
• I will no longer introduce fixes or custom code to handle conflicts created by third-party modules or templates. Each developer is responsible for their own software

I know this may be disappointing for some, but maintaining compatibility with unsupported versions or poorly designed third-party code is no longer viable. The focus has to be on stability, performance and long-term maintainability for the majority of users.

Here's what I accomplished in this first week:

• Adopted WHMCS's modern features: autoloaders, updated language handling and native developer tools now replace my old custom solutions
• Redesigned configuration storage: the new database structure is flexible and future-proof
• Introduced a dedicated logging system: multilingual, professional logs separated from the WHMCS activity log
• Optimized data handling: self-initializing, cached classes cut down on redundant queries and speed up performance
• Robust installer, uninstaller and updates: installation now provides detailed feedback, uninstall automatically creates backups and migrations include rollbacks to prevent fatal errors or data loss during updates

This is only the beginning, but the foundations for the future are in place. Whether I ultimately merge everything into one unified module or keep them separate, the path forward is clear: a cleaner, faster, more reliable codebase.

I can't and won't commit to timelines, since I'm also managing other projects and responsibilities. What I can say is that I'm actively working on this refactoring every week, step by step, with the goal of delivering something truly solid and long-lasting.

Side note: in the past few weeks I've received many requests about Spanish electronic invoicing, which will become mandatory next year. In fact, most of the logic behind e-invoicing in Spain (and in other countries) is very similar to the system that Billing Extension has been using for years in Italy: in theory, it would just require adapting the output.

That said, I don't plan to work on this, as it would conflict with the goals I've set for this refactoring phase. WHMCS has already announced that the next version will support electronic invoicing, so I encourage you to look to them for this feature.

Personally, I do have some doubts: true e-invoicing support requires deep structural and conceptual changes in WHMCS, along with extreme attention to detail. We'll see how it goes.