{"id":1409,"date":"2023-04-04T17:30:00","date_gmt":"2023-04-04T12:00:00","guid":{"rendered":"https:\/\/qalbit.com\/blog\/?p=1409"},"modified":"2026-07-30T15:26:43","modified_gmt":"2026-07-30T09:56:43","slug":"simplifying-web-development-with-codeigniter-hmvc-architecture","status":"publish","type":"post","link":"https:\/\/qalbit.com\/blog\/simplifying-web-development-with-codeigniter-hmvc-architecture\/","title":{"rendered":"CodeIgniter HMVC: Modules, PHP 8.2 Fixes, and the CodeIgniter 4 Question"},"content":{"rendered":"\n

Most people reading this are not starting a new CodeIgniter HMVC project. They are keeping an old one running.<\/p>\n\n\n\n

That is the honest state of this topic. Modular Extensions \u2013 HMVC gave CodeIgniter 3 something the framework never shipped: real modules, each with its own controllers, models, and views, callable from anywhere in the application. A lot of software got built that way between roughly 2011 and 2019, and a lot of it is still in production. Then PHP 8.2 landed, deprecated dynamic properties, and every one of those applications started filling its logs with the same warning.<\/p>\n\n\n\n

This guide covers three things, in the order people actually need them: the fix for the PHP 8.2 deprecation notices, how the HMVC module structure works if you are inheriting a codebase you did not write, and what your options are on CodeIgniter 4 \u2014 where the wiredesignz extension does not work at all. We do legacy CodeIgniter work<\/a>, so this is written from the maintenance side rather than the tutorial side.<\/p>\n\n\n\n

If you landed here from a search for a specific error message, skip straight to the next section.<\/p>\n\n\n\n

Fixing “Creation of dynamic property CI::$load is deprecated”<\/h2>\n\n\n\n

This is the error that brings most people here:<\/p>\n\n\n\n

Deprecated: Creation of dynamic property CI::$load is deprecated\nin \/application\/third_party\/MX\/Base.php on line NN\n<\/code><\/pre>\n\n\n\n
You may also see it as CI::$app->load<\/code>, or against other properties \u2014 CI::$config<\/code>, CI::$router<\/code>, CI::$db<\/code>. Same cause, same fix.<\/p>\n\n\n\n
Worth knowing up front: this is not really an HMVC problem. It is a CodeIgniter 3 problem that HMVC makes louder. The framework core throws the same class of notice on its own \u2014 there are reports against CI_URI::$config<\/code> in system\/core\/URI.php<\/code><\/a> and CI_Loader::$input<\/code> in system\/core\/Loader.php<\/code><\/a> with no HMVC involved at all. Patching the extension cleans up the extension. The core will keep going.<\/p>\n\n\n\n
Why it happens<\/h3>\n\n\n\n
PHP 8.2 deprecated dynamic properties<\/a>. Assigning to a property that was never declared on the class now emits a deprecation notice on first assignment:<\/p>\n\n\n\n
class Example {}\n\n$e = new Example();\n$e->something = 'value';\n\/\/ Deprecated: Creation of dynamic property Example::$something is deprecated\n<\/code><\/pre>\n\n\n\n
Modular Extensions \u2013 HMVC was written years before this rule existed, and it leans on dynamic assignment deliberately. The CI<\/code> class in MX\/Base.php<\/code> exists to mirror CodeIgniter’s loaded components onto module controllers, and it does that by assigning properties it never declared. Under PHP 8.1 that was normal. Under 8.2 it is a deprecation. Under a future major version it will very likely be an error.<\/p>\n\n\n\n
Two things worth knowing before you start:<\/p>\n\n\n\n
Your error message names the exact file and line.<\/strong> Do not go hunting. In a standard install it points at application\/third_party\/MX\/Base.php<\/code>, but if a previous developer moved things around it may not. Trust the trace over any tutorial, including this one.<\/p>\n\n\n\n
Nothing is broken yet.<\/strong> These are deprecation notices, not fatal errors. The application still runs. What they do is flood your logs, slow things down under volume, and occasionally leak into output if display_errors<\/code> is on in an environment where it should not be. So this is urgent in the sense that it will get worse, not in the sense that the site is down.<\/p>\n\n\n\n
Fix 1: #[AllowDynamicProperties]<\/code> \u2014 fastest<\/h3>\n\n\n\n
PHP 8.2 shipped an attribute that opts a class back into the old behaviour<\/a>. Add it above the class declaration in MX\/Base.php<\/code>:<\/p>\n\n\n\n
#[AllowDynamicProperties]\nclass CI\n{\n    \/\/ ... existing class body unchanged\n}\n<\/code><\/pre>\n\n\n\n
Two details that make this the pragmatic choice:<\/p>\n\n\n\n
The effect is inherited.<\/strong> Attributes themselves are not inherited in PHP, but the dynamic-property permission granted by AllowDynamicProperties<\/code> is \u2014 child classes of a marked class also allow dynamic properties without declaring the attribute themselves. Patch the base class and the subclasses are covered.<\/p>\n\n\n\n
It is safe on older PHP.<\/strong> In PHP 7.x, #<\/code> opens a comment, so the whole line is ignored rather than causing a parse error. If your deployment pipeline still touches PHP 7 anywhere, this will not break it.<\/p>\n\n\n\n
If the file uses namespaces, you need the leading backslash or an import, or PHP will look for the attribute inside the current namespace and silently fail to apply it:<\/p>\n\n\n\n
#[\\AllowDynamicProperties]\nclass CI { }\n<\/code><\/pre>\n\n\n\n
You will likely need the same attribute on MX_Controller<\/code> and MX_Model<\/code> in third_party\/MX\/Controller.php<\/code> and third_party\/MX\/Model.php<\/code>, since those assign loaded libraries onto themselves the same way. Run the app, read the log, patch what actually fires \u2014 rather than pre-emptively decorating every class in the directory.<\/p>\n\n\n\n
Fix 2: Declare the properties \u2014 cleaner<\/h3>\n\n\n\n
The attribute silences the warning. Declaring the properties fixes the underlying design:<\/p>\n\n\n\n
class CI\n{\n    public $load;\n    public $config;\n    public $router;\n    public $uri;\n    public $lang;\n    public $input;\n    public $output;\n    public $security;\n    public $benchmark;\n    public $db;\n\n    \/\/ ... existing class body\n}\n<\/code><\/pre>\n\n\n\n
The catch is that you have to know the full set, and the full set depends on which libraries your application autoloads. Miss one and it still warns. Work from your log: each notice names the property, so collect them over a full pass through the application before you start writing declarations.<\/p>\n\n\n\n
This is the right fix if you expect to be on this codebase for years, or if you are heading toward PHP 9 where dynamic properties are expected to become an error rather than a notice. It is the wrong fix if you are migrating off CodeIgniter 3 in the next six months \u2014 you would be doing careful work on code you are about to delete.<\/p>\n\n\n\n
Fix 3: Suppress the notice \u2014 do this only as a stopgap<\/h3>\n\n\n\n
\/\/ In index.php, or your environment's error_reporting call\nerror_reporting(E_ALL & ~E_DEPRECATED & ~E_STRICT);\n<\/code><\/pre>\n\n\n\n
This hides every deprecation notice in the application, not just this one. That means the next PHP version’s warnings \u2014 the ones that tell you what will break in the version after \u2014 are hidden too. It is a reasonable thing to do at 2am to stop a log partition filling up. It is not a fix, and if you use it, write yourself a ticket.<\/p>\n\n\n\n
Verifying it worked<\/h3>\n\n\n\n
Deprecation notices fire once per property per request, so a single page load is not a test. Clear your log, then exercise the routes that load the most libraries \u2014 usually an authenticated dashboard rather than the homepage \u2014 and check the log is still empty:<\/p>\n\n\n\n
> application\/logs\/log-$(date +%Y-%m-%d).php\n# hit several routes, then:\ngrep -c \"dynamic property\" application\/logs\/log-$(date +%Y-%m-%d).php\n<\/code><\/pre>\n\n\n\n
If you patched MX\/Base.php<\/code> and the notices moved to a different class, that is progress, not failure. Patch the next one.<\/p>\n\n\n\n
There is no upstream fix coming<\/h3>\n\n\n\n
Before you go looking for a patched release: there isn’t one, and there is nobody to wait for.<\/p>\n\n\n\n
The original Modular Extensions \u2013 HMVC lives in a Bitbucket repository<\/a> under Mercurial, and Bitbucket removed Mercurial support in 2020. The forks that exist on GitHub \u2014 codinghamster<\/code><\/a>, natanfelles<\/code>, brianwozeniak<\/code>, invitecomm<\/code>, and others \u2014 are mirrors with small routing or Composer improvements. None of them advertises PHP 8.2 compatibility. The codinghamster<\/code> fork is the most practical of them if you want Composer installation rather than copied directories, but it will not solve this for you either.<\/p>\n\n\n\n
That means the patch is yours to own, which makes the next point matter.<\/p>\n\n\n\n
Keep a record of the patch<\/h3>\n\n\n\n
You are editing a third-party library inside third_party\/<\/code>. The next developer who reinstalls the extension will wipe your fix without knowing it existed. Leave a comment above the attribute explaining what it is and why, and note it in the project README. If you installed via Composer, express it as a patch file rather than editing vendor\/<\/code> \u2014 otherwise the next composer install<\/code> silently undoes your afternoon.<\/p>\n\n\n\n
The PHP Version Problem Behind All of This<\/h2>\n\n\n\n
It is worth understanding why these notices appeared at all, because the answer determines how much more effort CodeIgniter 3 deserves.<\/p>\n\n\n\n
CodeIgniter 3’s final release is 3.1.13. The branch is in maintenance mode \u2014 critical security patches, no active development. Versions 3.1.12 and 3.1.13 added compatibility with PHP 8.0 and PHP 8.1<\/a>, and that is where official support stops. There is no CodeIgniter 3 support for PHP 8.2 or newer.<\/p>\n\n\n\n
Now put that next to PHP’s own release schedule<\/a>. PHP 8.1 reached end of life on 31 December 2025.<\/strong> The versions still receiving security support are 8.2, 8.3, and 8.4 \u2014 and PHP 8.2 is itself security-only, reaching end of life on 31 December 2026.<\/p>\n\n\n\n
Read those two paragraphs together and the position is uncomfortable: the newest PHP your framework officially supports no longer gets security patches, and every PHP version that does get patched is officially unsupported by your framework. There is no configuration that is fully supported on both sides. You are choosing which kind of unsupported you prefer.<\/p>\n\n\n\n
Running CI3 on PHP 8.2 or later is what most teams pick, and it works \u2014 with the deprecation notices this guide fixes, and with the understanding that you are now the maintainer of your own compatibility layer. That is a real, defensible choice. It is just worth making it deliberately rather than discovering it from a log file, and worth noting that 8.2 buys you less runway than it looks like.<\/p>\n\n\n\n
Some of the patching is genuinely small. The extension’s own documentation, for instance, tells you to extend the form validation library like this so that callbacks work:<\/p>\n\n\n\n
\/\/ application\/libraries\/MY_Form_validation.php\nclass MY_Form_validation extends CI_Form_validation\n{\n    public $CI;\n}\n<\/code><\/pre>\n\n\n\n
That public $CI;<\/code> is exactly the same declaration this whole guide is about \u2014 someone hit the dynamic-property problem long before PHP made it a deprecation, and solved it by declaring the property. The pattern you need is already in the codebase; PHP 8.2 just made it mandatory everywhere.<\/p>\n\n\n\n
How HMVC Actually Works<\/h2>\n\n\n\n
If you are maintaining a codebase someone else wrote, this is the mental model you need.<\/p>\n\n\n\n
MVC<\/strong> splits an application three ways. The model holds data and business rules, the view renders output, the controller mediates. One set of each, application-wide.<\/p>\n\n\n\n
HMVC<\/strong> \u2014 Hierarchical Model-View-Controller \u2014 makes that triad repeatable. Instead of one controllers directory for the whole application, each module gets its own controllers, models, and views, and modules can call each other. A blog<\/code> module can render a widget from a comments<\/code> module without either one knowing much about the other.<\/p>\n\n\n\n
The word doing the work is hierarchical<\/em>. A module’s request can trigger another module’s request, and that one can trigger a third. It is MVC that nests.<\/p>\n\n\n\n
In practice you get:<\/p>\n\n\n\n