Twig Extensions Bundle Laravel Package

Getting Started

This bundle is frozen in the Symfony 2.x/3.x era (last meaningful commits around 2013–2014, 2 stars, 0 dependents). Treat it as legacy-only: pull it in only if you are maintaining a project already on Symfony ≤3.4 or you want to cherry-pick individual extension classes.

Minimal steps:

1. Install via Composer (expect constraint friction on modern PHP/Symfony):

   composer require widop/twig-extensions-bundle
   

2. Register the bundle in app/AppKernel.php (Symfony 2/3 only — there is no Flex recipe and no auto-registration):

   new Widop\TwigExtensionsBundle\WidopTwigExtensionsBundle(),
   

3. Inspect vendor/widop/twig-extensions-bundle/Twig/Extension/ first — this is where the actual value lives. Typical classes you will find there:
   • ArrayExtension — array helpers (array_column, array_filter, array_unique, etc.)
   • ImageExtension — base64/inline image encoding
   • NumberExtension — ordinal, roman numerals, number formatting
   • PaginationExtension — page/offset helpers for Twig templates
   • TextExtension — truncate, slugify-style helpers
4. First use case: replace a pile of ad-hoc Twig filters with the bundle's filters, e.g. {{ price|number_format_currency }} or {{ items|array_column('id') }}.

If you are on Symfony 4+, do not install the bundle. Instead, copy the extension class you need into your own src/Twig/Extension/ and register it as a normal Twig extension — this bundle has no service auto-wiring and the bundle class will not be discovered.

Implementation Patterns

Pattern 1 — Template-level filter usage. The bundle's purpose is to expose extra filters/functions to Twig. Enable it as a bundle and just use the filters in templates; there is no per-filter config. Confirm what is actually registered by running:

php bin/console debug:twig

Scan the output for filters like number_format_currency, array_column, image, pagination_*, truncate. Only use what shows up — the bundle registers extensions unconditionally, so a debug:twig snapshot is the source of truth for your version.

Pattern 2 — Direct class usage (recommended for new code, even on Symfony 2/3). Skip the bundle wrapper and wire the extension yourself. This gives you control over the service definition and lets you drop the extension when you finally remove the dependency:

# app/config/services.yml (Symfony 2/3)
services:
    app.twig.extension.number:
        class: Widop\TwigExtensionsBundle\Twig\Extension\NumberExtension
        tags: [{ name: twig.extension }]

Pattern 3 — Progressive extraction. Because the bundle has 0 dependents and is effectively unmaintained, treat it as a temporary shim:

• Create a thin App\Twig\Extension\LegacyNumberExtension that extends the Widop class.
• Swap the DI tag from the Widop service to your subclass.
• Over time, reimplement the methods you actually call, then drop the parent.

This lets you keep a working template API (number_format_currency, etc.) while decoupling from the package.

Pattern 4 — Pagination helpers. PaginationExtension typically provides offsets/pages for Twig-side rendering. Use it in list/table templates, but push pagination state from the controller (e.g. a Pager object or KnpPaginator) rather than computing it inside Twig. This bundle does not have paginator integration — it is just math helpers.

Gotchas and Tips

• Maintenance status is the headline. 2 stars, 0 dependents, score 0.04. Do not adopt this for greenfield work. If you are auditing a legacy app, flag it as a removal candidate — most of these filters are now first-class Twig or trivially reimplementable.
• No Flex recipe / no Symfony 4+ support. The bundle class targets the old bundle-registration model. On Symfony 4+ it will not be discovered; register extensions manually via twig.extension tags instead of installing the bundle.
• PSR-0 autoloading. The original composer.json likely uses PSR-0 ("Widop\\TwigExtensionsBundle" : "" or src/). If you copy classes into a PSR-4 project, adjust namespaces or add a PSR-0 fallback to composer.json — otherwise filters silently vanish.
• PHP version drift. Old code may use removed functions (each(), ${var} interpolation, loose is_int checks around numeric strings). A php -l pass over Twig/Extension/ is a worthwhile 30-second sanity check before trusting it.
• No test coverage you can rely on. If you need to know what a filter does on edge inputs (nulls, empty arrays, non-UTF-8 strings), write a tiny PHPUnit test around the extension method rather than guessing from templates. Extension methods are public and easy to unit test in isolation.
• Silent registration. Because extensions are registered unconditionally, a broken extension method fails only when the template runs. Use debug:twig after install and again after any upgrade to catch drift.
• Deprecation noise. On Symfony 3.x you will likely see Twig_Extension deprecation notices (renamed to Twig\Extension\AbstractExtension in 2.x of Twig). These are cosmetic on 3.x but become hard errors on Twig 2+/Symfony 4+.
• Extension points you actually have. None in the modern sense — there is no config tree, no compiler pass, no event hook. Your only extension surface is subclassing the extension classes and overriding getFilters() / getName(). That is fine for a shim, but do not plan feature work on top of it.
• Debugging trick. If a filter that "should" exist is undefined in Twig, the cause is almost always (a) bundle not registered in AppKernel, or (b) composer autoload not regenerated. Run composer dump-autoload and re-check debug:twig before digging into the extension source.