11. Risks and technical debt¶
Risk register¶
| Risk | Impact | Current mitigation | Direction |
|---|---|---|---|
| Mixed procedural and object-oriented design | Changes cross hidden global and include dependencies | Shared bootstrap and class families | Move cohesive workflows behind explicit services |
| Global configuration variables | Invalid combinations and difficult tooling | Defaults, comments, runtime validation | Introduce typed configuration access incrementally |
| Large bootstrap surface | Every request can be affected by integration or upgrade code | Fixed include order and checks | Separate boot phases and narrow side effects |
| Bundled legacy libraries | PHP compatibility and vulnerability exposure | Manual upgrades and fixes | Inventory ownership and automate compatibility scanning |
| Limited automated test suite | Regression risk in policies, databases, and integrations | Targeted scripts and manual verification | Add repeatable unit and integration tests |
| Runtime schema upgrade | Elevated credentials and partial-upgrade risk | Version tracking and prompts | Provide explicit preflight and CLI migration path |
| External CMS code loaded in-process | Autoloader and interface conflicts | Session initialization ordering | Prefer protocol/API integration where feasible |
| Configuration and docs drift | Operators use obsolete examples | Comments near defaults | Generate reference material and version docs |
Notable structural debt¶
Shared global functions¶
Page controllers depend on broad include files and global variables. This makes the real interface of a workflow larger than its function signature.
Legacy third-party code¶
Some libraries under web/File, web/Mail, and other bundled directories
originate from older PHP ecosystems. A file can pass through normal MRBS use
while an optional class still contains incompatible syntax or runtime calls.
Integration matrix¶
Authentication and session strategies produce many possible combinations. Not every third-party provider can be exercised in a normal continuous integration environment.
Database parity¶
MySQL and PostgreSQL differ in SQL, locking, identifiers, and driver behavior. A change verified on only one database carries material regression risk.
Prioritization guidance¶
Address debt when it:
- blocks a supported PHP or database upgrade;
- weakens authorization or data integrity;
- makes security patches difficult to verify;
- causes repeated defects in the same workflow; or
- prevents representative automated tests.
Refactoring should preserve user-visible behavior and be split from unrelated feature changes where practical.