OpenEMR Weekly Conference Call Notes 2026-07-07

psoas · July 16, 2026, 7:11pm

Main Topic: Modules

Eric is developing a new module architecture and recently posted a preliminary PR for review. He gave an overview of his creation during the meeting.

He proposed renaming “Modules” to “Plug-ins”

Features:

Install via composer
Use Doctrine for database access (instead of aodb)
Schema migrations
Command line tools
Well defined api’s

Goals:

Well defined interface
Not having modules break with upgrades

Future:

Pluggable Auth

Plugin manager:

Database migrations
Add cli tooling and routing

Design Issue:

New plug-in architecture will not support asynchronous events
Concerns were expressed about dropping asynchronous events

Someone commented that new architecture is similar to how laminus modules work
It would be nice to Migrate laminus modules to new architecture.

Proposal:

Further discuss new module design & architecture on 7/21/2026 conference call.

Link to Plug-In PR:

github.com/openemr/openemr

feat(plugins): RFC: Plugins (a.k.a. modules 2.0) (#12643)

master ← plugin-api

opened 01:10AM - 26 Jun 26 UTC

Firehed

+727 -24

It's here. Or here enough to start discussing. (I'll probably keep updating this… description) This is the bulk of what remains in #10714. It omits a few things (some deferred, some intentionally omitted), and there are a few incidental things I need to clean up. I strongly suggest reading that issue and those it links to have enough context here. ## Goals This provides hooks for three core use-cases for developers (both core and external) of OpenEMR: - API endpoints - Command-line tools - Schema migrations This does _not_ aim to be backwards-compatible with the existing infrastructure, **but will not break it**. It also doesn't (yet) aim to do everything that it might ever need to do. Before developers can really start building on this, we need to make two corresponding changes: - Officially direct requests through the front-controller (e.g. provide server configs for the docker images, etc). In-flight - Complete the migration from the home-grown schema management tooling to doctrine/migrations. In-flight We'd also want to combine the experimental and official CLI tooling, but this is not a blocking requirement. ## Structure This is divided into a few things: - Core updates - An interfaces Composer package - An installer Composer plugin The latter two are necessarily split into separate repositories (one for the developers, one because that's how Composer works). I've put demos up, linked below. If we move forward with this, they'd move under ownership of the OpenEMR org after being tidied up a bit ### Interfaces https://github.com/Firehed/openemr-plugin-interfaces This leverages Composer+Packagist so that plugin developers have stable interfaces to work with. While OpenEMR itself doesn't use Semantic Versioning for its version scheme (it doesn't make sense in the context of end-user applications), the interface package does. This provides a contract to developers: Any plugin developed targeting `^1.0` of the interface package is _guaranteed_ to work in any OpenEMR version that provides the 1.x line. It also means we can go both directions: if we add more functionality support to plugins (say, another XyzPluginInterface), that gets added into `1.1`; any OE that vends interfaces `1.1` or higher provides the same guarantee. Done correctly, this covers us for a _long_ time, and dramatically reduces the chance that a plugin breaks during any given release. Worst-case should be a setup-time warning from composer about the compatibility issue. ### Installer https://github.com/Firehed/openemr-plugin-installer/tree/v1 The design is highly inspired by PHPStan's extension installer. It generates/updates a static manifest of plugin packages, which is then read by the application (`PluginManager`, which calls `GeneratedInstalledPlugins::getPlugins()`). This mostly exists to avoid expensive parsing of composer data on every request. This is only a separate package due to how Composer itself works, otherwise it would be included in core. Unavoidable, unfortunately (the existing module installer works similarly). ### Core There's a very low-level hook in the bootstrap file (currently only used in the dormant new paths: the front controller & experimental CLI). It's used to merge plugin configs w/ the application container. Each of the three aforementioned pieces of functionality have a corresponding integration hook in core: - API Plugins are hooked in the front controller - CLI Plugins are hooked in the CLI entrypoint - DB Migration plugins are hooked in the migrations tooling config At present, I'm using `slim` for API routing, as I think the added flexibility it provides works well in this context. It's part of the integration I don't love _yet_ since the bootstrap process hard-ties to the package; I think that's fixable if we think it's important enough. This is also true for the other paths, but I'm less concerned given their _massive_ presence in the PHP ecosystem (Slim is well-known; Doctrine is everywhere). #### Manager The installer only tracks a list of what plugins are physically installed on the filesystem. That alone does nothing: we need to know what's _active_ and should actually be exposed to the runtime. This is what the `PluginManager` and its `Activation\StateProvider` do: figure out what needs to be exposed. The manager itself is fairly straightforward: filter some core operational hooks to plugins that are both active and provide the relevant tools. The activation state providers... determine what plugins are active. You'll see two implementations provided: EnableAll and DisableAll. Both do what the name implies. The former is mostly to make initial development easy. The latter will enable "safe mode" operation in the future: just run the core, without any external tooling. We'll have other providers that have _actual_ logic. They could source settings from a database, environment variables, config file, remote feature flag system, whatever. ## Example https://github.com/Firehed/openemr-plugin-example/tree/example WIP, meant to demonstrate what development looks like. I was able to write this code without OE running at all, and it can be 100% unit-tested (a community example will have tests like this added). Note that it doesn't depend on OpenEMR directly, just the interface package. ## Errata I've gone with "plugin" rather than sticking with "module" for a couple reasons: - It separates the discussion so that we don't have _three_ types of modules - It prevents some internal naming collisions, especially around Composer-specific tooling ## Still To Do - Create the activation/deactivation tooling (I think pre-launch, we can omit this, and treat installed=active as the demo does now) - Finalize the plan for module DB uninstallation - Documentation - Authentication and authorization strategy. tl;dr: middleware, but I recognize that's a short explanation for a very important concept - "Certification" process - this is not needed upfront, but it's front-of-mind for quality standards - Formally expose the library-provided interfaces that we _want to provide_ in the interface package (this is not complete yet, and where it's done it's too wide-reaching)