evoluted/twigtools-plugin
Evoluted's Twig Tools plugin extends Twig template handling in Laravel/PHP projects, adding helper functionality for rendering and working with Twig views. Install it via Composer to integrate the tools into an existing Twig-based setup; see the repository for configuration details.
Public footprint is minimal (0 stars, 0 dependents, single vendor). Treat everything below as "verify against the source before you build on it" — start by reading the addon's
composer.jsonand its TwigExtensionclass, which are the two files that define everything this package does.
1. Install it as a dev-only dependency. It is a PyroCMS 3 addon, so it must live under addons/{vendor}/{slug} — installing into vendor/ alone will not get it auto-discovered. The safest route for an unmaintained repo is a VCS requirement pinned to a commit:
"repositories": [
{ "type": "vcs", "url": "https://github.com/EvolutedNewMedia/twigtools-plugin" }
],
"require-dev": {
"evoluted/twigtools-plugin": "dev-master#<commit-sha>"
}
Then place/symlink it into addons/evoluted/twigtools-plugin and run php artisan addon:install evoluted.twigtools_plugin (Pyro's addon slug convention uses underscores; check the addon's composer.json extra.pyro block for the exact slug).
2. Find the registration point first. Open the addon's service provider and look for Twig::addExtension(...) / $this->app['twig']->addExtension(...) in register() or boot(). That call — and the Extension class it instantiates — is the entire surface area of the package. Its public methods (filters, functions, tests) are your available API; there is no other documentation to lean on.
3. First use case: a local-only template debugging loop. Take one of your existing Pyro page/theme views, add the addon's context-dumping helper at the top of the layout, and use the output to confirm the shape of the variables Pyro passes in (page, stream entry models, meta_* fields). Remove it, then gate the whole extension behind the environment:
// app/Providers/AppServiceProvider.php — namespace per the addon's composer.json
public function boot()
{
if ($this->app->environment('local', 'staging')) {
$this->app['twig']->addExtension(
new \Evoluted\TwigTools\TwigToolsExtension()
);
}
}
That single guard is the difference between "useful dev tool" and "leaked internals in production."
Environment-gated registration. Never let the addon auto-register in production. Either keep it in require-dev and install only on local/staging checkouts, or wrap the addExtension call as above. If the addon registers itself via its own service provider, disable it in config/app.php/config/streams.php for prod and register manually in a local-only provider.
Template-shape reconnaissance. The highest day-to-day value on Pyro is answering "what does this template actually receive?" Use the addon's dump helper inside a layout or partial, read the array shape, then translate that into concrete Twig — e.g. discovering a stream field is an Entry model with ->presenter() accessors rather than a flat value. Do the dump in a {% if app.environment == 'local' %}-style guard so you can commit it temporarily without risk.
Pair with Pyro's own Twig extension set. Pyro already registers extensions for url, page, streams, and localization. When adding third-party filters, register yours after the framework's to avoid name collisions silently overriding a core filter. If a filter stops behaving, the first thing to check is registration order, not the addon.
Use it while developing your own addons. When building a custom Pyro addon, this is a cheap way to inspect the data your repository/presenter() returns before it reaches a view — faster than dd() in the controller for nested stream relationships.
Editor/IDE support. Because you're working from source, mirror the extension's functions/filters into a small twig-doc/PhpStorm Twig stub or an _ide_helper-style doc block. With no published API docs, this is the only way your team gets completion for custom tags.
Smoke test it in CI (or drop it from CI). Add a single assertion that the extension is present when the environment is local: Twig::getExtensions() should contain the class. That catches the upgrade breakage described below before a designer does.
dev-master branch that can move under you. Always pin the commit SHA.vendor/. If Unknown filter/Unknown function errors persist after composer require, check addons/evoluted/ exists and the addon is registered in config/streams.php / the addons manifest.Twig_Extension to Twig\Extension\AbstractExtension and filters moved to TwigFilter/TwigFunction classes. On a Pyro/Laravel upgrade this package will likely fatal with a class-not-found rather than a clean error — grep for Twig_ prefixes before you upgrade.php artisan view:clear. Pyro compiles into storage/framework/views; stale compiled classes are a common false negative when testing.dump() needs debug on. Twig's dump is only available when debug is enabled in the Twig config. If the addon wraps dump, a no-op or missing function usually means debug is off, not that the addon is broken.dump() is fatal in JSON/AJAX responses and can expose config secrets in rendered HTML. Grep for the addon's helper names in your pre-deploy checklist.vendor/ or addons/. Override behaviour by writing your own AbstractExtension in app/Twig/ and registering it in a project provider — otherwise your fixes vanish on composer update.Twig\Error\SyntaxError line numbers can point into the compiled template, not your source. Open the compiled file in storage/framework/views to find the real location.Twig::addExtension() ordering in the service provider, and the addon's resources/config/ if it exposes toggles — that config file is usually the fastest way to enable individual helpers selectively rather than all-or-nothing.How can I help you explore Laravel packages today?