Dynamically Configurable Mjr Bundle Laravel Package

Getting Started

• Install with Composer: composer require modera/dynamically-configurable-mjr-bundle. Because the last release is from 2016, pin a compatible version and expect Symfony 2.x/3.x-era dependencies; modern Symfony projects will usually need a fork rather than a direct install.
• Register the bundle in AppKernel (or bundles.php only if you have backported support): new Modera\DynamicallyConfigurableMJRBundle\ModeraDynamicallyConfigurableMJRBundle().
• Confirm the Modera stack it depends on is present — typically the Modera admin/backend bundle, a config storage bundle, and the MJR bundle being configured. Without those, the UI and persistence layer will not boot.
• Look first at:
  • Resources/config/services.xml / DependencyInjection/Configuration.php for service IDs and config keys.
  • Controller/ and Resources/views/ for the admin UI entry points.
  • The bundle README and any docs/ folder for the expected MJR settings keys.
• First use case: log into the Modera admin UI, open the MJR configuration panel, change one low-risk setting (for example a route or endpoint option), save it, and verify the value is persisted and consumed by MJR. This confirms the full UI → storage → MJR runtime path before you automate anything.

Implementation Patterns

• Treat the bundle as an admin-editable settings layer over MJR. Keep environment defaults in Symfony YAML and use the UI for runtime overrides that operations need to change without redeploying.
• Read configured values through the bundle’s config/provider service rather than reading the database directly. Inject the service into your own MJR integration code so tests can substitute an in-memory provider.
• When extending MJR behaviour, resolve the dynamically configured values at the point MJR is initialised (request listener, MJR config factory, or a service decorator), not at container compile time — otherwise UI changes will not take effect until cache clear.
• Common workflow:
  1. Developer sets baseline MJR options in application config.
  2. Admin user adjusts MJR options in the Modera UI.
  3. Application reads the merged result through the bundle’s provider.
  4. MJR routing/configuration consumes that result per request.
• For feature flags or staged rollouts, use the UI to toggle MJR settings per environment or per tenant if the bundle’s storage supports scopes; otherwise keep environment-specific values in YAML and only expose safe, global options in the UI.
• In integration tests, mock the config provider service and assert your MJR wiring uses the mocked values. This is faster and more reliable than exercising the admin UI.
• If you need custom MJR options, prefer decorating the bundle’s config provider or adding a small compiler pass that registers your own settings, rather than editing vendor code.

Gotchas and Tips

• This bundle is effectively abandoned: zero stars, no dependents, last release in 2016. Expect Symfony 2/3 conventions, PHP 5.x compatibility, and no autowiring. Budget time for a fork or replacement if you are on Symfony 4+.
• The admin UI likely depends on Modera’s backend assets and ExtJS-era frontend stack. A blank or non-functional panel usually means missing assets, unpublished bundles, or an incomplete Modera admin installation.
• Dynamically configured values may be cached. After changing settings in the UI, clear the Symfony cache or trigger the bundle’s cache invalidation path; otherwise MJR may keep using stale values.
• Check the database schema. The bundle probably stores settings in a Modera config table. Run the expected migrations or doctrine:schema:update in non-production environments and verify rows are written when you save the UI form.
• Access control matters: the configuration UI can change MJR behaviour globally. Restrict the admin route to trusted roles and audit changes if the bundle does not provide history.
• Debugging tips:
  • Use debug:container to find the config provider and MJR integration service IDs.
  • Inspect the Modera config table directly to confirm persistence.
  • Enable Symfony debug logging around MJR initialisation to see which values are actually consumed.
  • If the UI saves but MJR ignores the value, trace whether the MJR integration reads from the bundle’s provider or from static parameters.
• Extension points are limited by age. Prefer service decoration, a custom config provider, or a small event listener over patching the bundle. If you fork, keep the UI contract and storage schema stable so existing admin workflows continue to work.