Request Plugin Laravel Package

Getting Started

anomaly/request-plugin is a Twig plugin for the Anomaly Labs Streams Platform (the engine behind PyroCMS 3.x). It exposes the current HTTP request to templates so page/partial authors can read query strings, headers, and route data without writing a controller. Treat it as a template-layer helper, not an application-layer HTTP abstraction.

Minimal steps:

1. Confirm your platform version first. Last release was 2015-08-01 against Streams 1.x. If you are on a modern Streams/Laravel (10+), this will almost certainly fail on install or boot. Only pull it into a legacy Pyro 3 project, and pin it: composer require anomaly/request-plugin:^1.0.
2. Read src/ before anything else. The package is undocumented. The three files that matter are the service provider (addon registration), the plugin class (usually RequestPlugin), and the functions class that declares the Twig functions()/filters(). That functions class is the API surface — the method names are your template vocabulary.
3. Verify registration. Streams addons self-register via the service provider listed in composer.json (extra.streams or extra.laravel.providers). Confirm php artisan addon:list (or the CP Addons screen) shows it as enabled before blaming the templates.
4. First use case: a landing page that personalises copy from a campaign parameter — {{ request.get('utm_campaign') }} in a page layout, with a default when absent. This is the lowest-risk introduction because it touches one template and is trivially removable.

If the package is not already in your composer.lock, seriously consider a five-line custom Twig extension instead; you will get the same feature with maintained dependencies.

Implementation Patterns

Template-only reads. The intended pattern is read-only, side-effect-free access from Twig partials and page layouts:

{% set ref = request.get('ref') ?: 'direct' %}
<p>Referred by {{ ref|e }}</p>

Keep all request access in one reusable partial (partials/request-banner.twig) rather than sprinkling calls through page bodies. When you eventually migrate off the addon, you swap one file instead of grepping every template.

Branching on request shape. Because the plugin gives templates visibility into method/path/headers, page authors can render different blocks per entry point — e.g. showing a compact hero on ?embed=1. Prefer this only for presentation toggles. For anything behavioural (auth, redirects, pricing), do it in the controller and pass a boolean into the view; templates should not own logic.

Pairing with the Pages module. The natural integration is a custom page type whose view partial reads the plugin, so the page stays editable in the CP while still varying by query string. This is the one pattern where the plugin genuinely saves work versus passing data through a controller.

PHP-side coexistence. Do not replace Laravel's request() with the plugin in controllers or middleware — the plugin is Twig-scoped and adds no value there. The clean split is: controllers use request() and validate; templates use the plugin only for cosmetic/optional values. Mirror that in tests: a feature test that hits the route with ?utm_campaign=spring and asserts the rendered string is the right contract, and it shields you from the addon's internals.

Defensive defaults. Wrap every lookup so a missing key does not blank the page:

{{ request.get('promo', 'none')|e }}

Adopt this as a house rule in code review; it turns the plugin from a footgun into a stable helper.

Gotchas and Tips

• It is effectively abandoned. Zero stars, zero dependents, last commit 2015, no maintainer. Plan for removal from day one. If you adopt it, fork it into your own vendor namespace so a packagist yank cannot break your build.
• Escaping is on you. Every value it returns is attacker-controlled. Autoescape covers the common case, but any |raw next to a plugin call is an XSS hole. Never feed plugin output into href, src, or inline <script>.
• Function-name collisions. Newer Streams releases ship their own request helpers in core Twig. Installing this alongside a modern platform can produce "unknown function" or, worse, a silent override where your template resolves to a different implementation than you expect. Dump the registered Twig functions in a tinker session to confirm which one wins.
• Silent empty output. Most likely failure mode on a version mismatch is not an exception but an empty string, because the addon never registered. If {{ request.get('x') }} renders blank, check addon enablement and provider registration before touching the template.
• Debugging. With Twig debug on, use {{ dump(request) }} to see exactly what the plugin exposes; otherwise log from a throwaway route. Do not add var_dump inside the plugin class — Streams' addon bootstrapping will produce unreadable output mid-render.
• The escaping filter ordering matters. Apply |e (or |escape) as the last filter in a chain, after defaults and string manipulation, or you will double-escape and see & in the wild.
• Extension point. The only sane way to extend it is to subclass the plugin and re-register your class in your own service provider, or better, write a small Twig extension and register it via Twig::extend. The latter is ~20 lines, has no abandoned dependency, and is what I would do if the plugin were not already in production.
• Composer pin. If you keep it, use an exact version constraint (1.0.x, not ^1.0) and commit the lockfile. With no upstream activity, floating constraints buy you nothing and risk a future tag you have not tested.