Many plugin systems load every enabled plugin on every request. This is simple to implement, but the startup cost grows as the platform grows. A request that only needs one feature still pays the cost of discovering, loading, and registering code that it will never use.

We only load a small manifest during application startup. The manifest contains metadata about the plugin, the actions it provides, and the classes responsible for handling them. The application keeps this information in memory and delays loading the actual code until a request asks for a specific action.

This keeps the startup cost predictable. A platform with fifty plugins and hundreds of available actions does not need to load hundreds of files on every request. Each request only loads the code it will execute.

This approach works particularly well in PHP because every request starts with a fresh process. Even with OPcache enabled, loading unnecessary files still requires filesystem lookups, class registration, and additional memory usage. Reducing that work improves response times and keeps memory usage more consistent under load.

Adding new plugins also becomes cheaper. Installing a plugin only adds another manifest for the application to discover. Existing requests do not become slower simply because more plugins are available.

Delayed loading introduces a trade-off. Errors that would normally appear during application startup can remain hidden until a user executes a specific action. An incorrect manifest entry, a missing file, or a renamed class may not be discovered until that path is used.

We avoid this by validating plugin manifests during deployment. Every manifest entry is checked against the files it references before the release is published. This catches missing dependencies early and prevents users from discovering configuration errors themselves.

Delayed loading also makes dependency tracking harder. Development tools can easily follow direct code references, but they cannot always trace relationships described through configuration files. Static analysis and deployment checks become more important once plugins are discovered dynamically.

This pattern is useful when the gap between installed code and frequently used code is large. A platform with dozens of plugins and hundreds of optional features benefits from loading code on demand. A smaller application with only a handful of features usually does not. In those systems, loading everything upfront is often simpler and easier to maintain.


Maybeach Tech designs plugin systems that match how a platform is actually used, not just how it looks on a diagram. Get in touch if you want to talk about how your code loads.

Related Post

The Maintenance Routine That Keeps a Production PHP/MySQL Server Healthy

A server that is set up well on day one does not stay healthy on its own. Logs pile up. Caches grow....

Designing RBAC for Multi-Location Organizations

A permission model that works fine for a single location business almost always breaks the first tim...