Rulesengine Bundle Laravel Package

Getting Started

Reality check first. opifer/rulesengine-bundle is archived, last tagged in May 2015, with 2 stars and zero dependents. It targets Symfony 2.x and PHP 5.x. Do not adopt it for new work — the only legitimate use is maintaining an existing Symfony 2 application that already depends on it (or mining it for design ideas). Everything below assumes that context.

Minimal install (legacy Symfony 2 app):

composer require opifer/rulesengine-bundle:dev-master

There is no maintained tag line, so you will likely pin a commit hash rather than a version constraint. Then register the bundle in app/AppKernel.php:

new Opifer\RulesEngineBundle\OpiferRulesEngineBundle(),

If the bundle ships an admin/CRUD controller for managing rules, import its routing in app/config/routing.yml; otherwise you only need the service layer and can ignore routing entirely. Check Resources/config/ to see whether routing and Doctrine mappings are actually provided before wiring anything.

Where to look first, in order:

1. Resources/config/services.xml — the real API surface. Service IDs changed across bundles of this era; this file is the source of truth for what to inject.
2. RuleEngine.php / RuleManager.php (or equivalent) — the evaluation entry point and its method signature.
3. The Rule model — how conditions and actions are stored (array, JSON column, or serialized PHP).
4. DependencyInjection/Configuration.php — what is configurable under opifer_rules_engine: in config.yml.
5. Tests/ — usually the only surviving documentation for a 2015 bundle.

First use case. The canonical fit is a persisted business rule evaluated against a domain object: "orders over €100 ship free," "show this block to users in segment X," "apply 10% discount when cart has 3+ items and customer is returning." You define a Rule with a set of conditions and a set of actions, persist it, then evaluate it against a context object at the point in your application where the decision is needed.

Start by hardcoding one rule in a fixture, evaluating it in a console command or a unit test, and printing the result. Do not start with the admin UI — you need to understand the evaluation contract before you can trust anything generated through a form.

Implementation Patterns

Rules as data, not code. The value of this bundle over plain if statements is that rules live in the database and can be edited without a deploy. Lean into that or don't use it at all. Model your Rule as a Doctrine entity with conditions and actions columns; if the bundle serializes to JSON, keep a schema_version column alongside so you can migrate rule definitions when the shape changes.

Evaluation at a service boundary. Inject the engine into your own service rather than calling it from controllers:

class ShippingPolicy
{
    private $ruleEngine;

    public function __construct($ruleEngine) // service id from services.xml
    {
        $this->ruleEngine = $ruleEngine;
    }

    public function qualifiesForFreeShipping(Order $order)
    {
        $rule = $this->ruleRepository->findOneByCode('free_shipping_over_100');
        if (!$rule) {
            return false; // fail closed, and log it
        }

        return (bool) $this->ruleEngine->evaluate($rule, $order);
    }
}

Wrapping the engine in a domain-named method (qualifiesForFreeShipping) means that when you eventually rip the bundle out — and you should plan for that — you change one class instead of every call site.

Context objects. Pass a single object or associative array that the conditions can read from. Keep the context shallow and explicit; deep object graphs read through getters are where these engines break, because a null in the middle of a path throws instead of evaluating false. If the engine dereferences properties reflectively, build a flat DTO (['total' => ..., 'itemCount' => ..., 'customerType' => ...]) before evaluating.

Action dispatch. Rules that "do" things rather than just return booleans should map action names to services, not to arbitrary callables. Register a small action registry:

$container->get('app.rule_actions')->register('send_coupon', function ($ctx) {
    // ...
});

If the bundle has a tag for actions (look for addCompilerPass in the bundle class), use it — it gives you lazy loading and makes actions discoverable in the admin UI.

Event listener integration. For request-time decisions (content visibility, feature gating), evaluate in a kernel.request listener and stash the result on the request attributes rather than evaluating repeatedly in templates. For domain events (order.placed, user.registered), evaluate in the listener that owns that event.

Caching. Rules are read-mostly. Load them once per request through a repository method that memoizes, and if you have a cache layer, key on rule code plus a version counter bumped on save. Never call findAll() inside a loop.

Testing. Write a table-driven test per rule: a list of contexts and expected outcomes. Because the evaluation logic is data-driven, these tests are your regression suite when someone edits a rule in the admin UI. If the bundle's test suite still runs, keep it in CI as a canary for the underlying PHP/Symfony versions you're pinned to.

Escape hatch. Keep an interface (RuleEvaluatorInterface) in your own namespace and make the bundle's engine one implementation. That is the single highest-value pattern here, given the package's status.

Gotchas and Tips

Abandoned and unpatched. No security fixes since 2015. If rule definitions are user-editable, you are exposing an expression/callback evaluation surface with no upstream maintenance. Audit how conditions are compiled — if it uses Symfony's ExpressionLanguage or eval, treat every rule author as a trusted developer, not a content editor.

PHP and Symfony version walls. Expect incompatibilities with PHP 7.2+ and certainly PHP 8 (reserved words, each(), dynamic properties, ReflectionParameter::getClass() deprecations). Running this on modern PHP means forking and patching. Budget for that, or vendor the evaluation classes into your own codebase and drop the bundle wrapper.

Service IDs are guesswork. Documentation is gone and the repository is archived; do not trust blog posts or the README's examples, they may predate the final refactor. Always confirm against Resources/config/services.xml and use debug:container (or container:debug on Symfony 2) to see what is actually registered.

Configuration key mismatch. Bundles of this vintage often have a Configuration.php that defines a tree (opifer_rules_engine: with driver, class keys) while the extension silently ignores parts of it. Test config changes by dumping the resolved parameter rather than assuming the YAML took effect.

Doctrine mapping conflicts. If the bundle ships XML/YAML mappings for a Rule entity and you also want your own entity extending it, you will hit mapping-driver conflicts. Prefer mapping the bundle's model to your own table via resolve_target_entities, or override the class in config if the bundle supports it.

Silent false negatives. Engines of this era typically return null or false when a condition references a missing property instead of throwing. A rule that used to fire and now doesn't may be a renamed field, not a logic bug. Log the evaluated context alongside the result at debug level, and diff the context shape after any domain model change.

No sandboxing, no limits. There is no recursion guard or evaluation timeout. A malformed rule that references a collection can loop indefinitely. Cap the number of conditions per rule and validate on save.

Debugging workflow. Since the profiler integration is unlikely to exist, add a thin decorator around the engine that logs rule code, context summary, result, and duration to a dedicated channel. This is ten minutes of work and will save you days.

Exit strategy. Treat the bundle as a temporary dependency: extract the evaluation logic behind your own interface, port the rule storage to a schema you own, and replace the evaluator with Symfony's ExpressionLanguage or a maintained rules library. The rules themselves — the data — are the durable asset; the 2015 wrapper is not.