Twig Extensions Bundle Laravel Package

Getting Started

First, know what you're getting. Despite appearing in PHP package lists, this is a Symfony bundle that wires the mapado/twig-extensions library — a thin Twig wrapper around PHP's parse_url() — into a Symfony DI container. It is not a Laravel package. There is no service provider, no Blade integration, and nothing in config/ to publish. As a Laravel developer, your realistic leverage point is the single Twig extension class inside src/, not the bundle wrapper.

Where to look first. Open the package's src/ directory and read the extension class end to end — it's a couple of minutes of reading. Confirm exactly what it exposes (a Twig filter, a function, or both), the argument order, and whether a component argument is supported. That determines how you reproduce the behavior in Blade.

Two paths depending on your stack:

Laravel + Blade (the default, 90% case). Do not composer require this. Reproduce the ~15-line capability as a Blade directive:

// app/Providers/AppServiceProvider.php
use Illuminate\Support\Facades\Blade;

Blade::directive('host', function ($expression) {
    return "<?php echo parse_url({$expression}, PHP_URL_HOST) ?: ''; ?>";
});

<a href="{{ $user->website }}">{{ @host($user->website) ?: $user->website }}</a>

Laravel + Twig bridge (rcrowe/twigbridge), or a Symfony app. Register the extension class directly via the bridge's extension list and skip the bundle entirely. On genuine Symfony, composer require mapado/twig-extensions-bundle then add Mapado\TwigExtensionsBundle\MapadoTwigExtensionsBundle::class => ['all' => true] to config/bundles.php — no YAML needed.

First use case — you have a URL in a template (entity field, CMS block, profile) and need one piece of it:

{% set parts = parse_url(user.website) %}
<a href="{{ user.website }}">{{ parts.host|default(user.website) }}</a>

That is the whole job: show a clean domain instead of a full URL. If the extension accepts a component constant (e.g. parse_url(url, 'host')), prefer it over grabbing the whole array.

Implementation Patterns

Clean host / path display

@php $host = parse_url($item->link, PHP_URL_HOST); @endphp
<a href="{{ $item->link }}">{{ $host ?: $item->link }}</a>

Twig equivalent, guarding against false returns:

{% set u = parse_url(item.link) %}
{% if u is iterable and u.host is defined %}
    <a href="{{ item.link }}">{{ u.host }}</a>
{% else %}
    <span>{{ item.link }}</span>
{% endif %}

Internal vs. external link branching. Compare against the app host passed in from a view composer or global — do not reach for app.request.host inside Twig in a Laravel/Twig bridge context, it won't be there reliably.

@php $host = parse_url($link, PHP_URL_HOST) ?: ''; @endphp
@if($host === config('app.url_host'))
    {{-- internal styling --}}
@else
    <span class="external" rel="noopener">{{ $host }}</span>
@endif

SEO / Open Graph metadata. This is where URL parsing pays off daily — canonical URLs, og:url, og:site_name, sitemap-ish views:

@php $canonical = parse_url($page->canonical, PHP_URL_HOST); @endphp
<meta property="og:url" content="{{ $page->canonical }}">
<meta property="og:site_name" content="{{ $canonical }}">

Query-string handling needs your own code. The extension gives you query back as a raw string. The moment a template needs ?page=2 as a key/value map, you've outgrown it. Add a small helper rather than string-splitting in Blade:

// app/Support/Url.php
public static function queryParams(?string $url): array
{
    $query = parse_url((string) $url, PHP_URL_QUERY);
    if (!$query) {
        return [];
    }
    parse_str($query, $params);
    return $params;
}

@php $params = \App\Support\Url::queryParams($url); @endphp
<a href="{{ url()->current() }}?page={{ (int)($params['page'] ?? 1) + 1 }}">Next</a>

Push normalization into the controller/service layer. Anything beyond presentation — building redirects, comparing URLs, deduplicating sitemap entries — belongs in PHP, not in a template. Templates are the wrong place to branch on URL structure. Compute a view model (['host' => ..., 'path' => ...]) in the controller and pass it down; the template just renders.

View composer for repeated parsing. If the same URL parse shows up across many views, bind it once:

View::composer('partials.link-card', function ($view) {
    $view->with('host', parse_url($view->getData()['link'] ?? '', PHP_URL_HOST) ?: '');
});

Gotchas and Tips

• License is NOASSERTION. No confirmed SPDX grant of rights. This is a legal-review blocker in most orgs and, given the trivial payload, has zero compensating upside. Extract or reimplement — do not ship the dependency.
• parse_url() returns false on severely malformed input. The extension's handling of that case is unverified. Always guard (?: '', or test is iterable in Twig) or your templates will emit warnings/fatals on bad data.
• It's a Symfony bundle — it will not autoload in Laravel. Attempting to register it via a Symfony-compat shim leads to opaque container-compile failures. Just don't declare the dependency; copy the extension class if you need it.
• Twig 1/2/3 have incompatible extension signatures (getName() removal, base class changes). If you extract the class into a Twig3 bridge, be prepared to adapt it — test with a fixture that renders the filter against a valid URL, a relative URL, and garbage.
• query is a string, not an array. The most common surprise. parse_str it yourself.
• Zero maintenance upstream. 0 stars, 0 dependents — assume the repo is frozen. No CVE response, no fixes. Anything you take on, you own from day one.
• The bundle wrapper is dead weight in Laravel. Target the extension class (framework-agnostic, implements Twig\Extension\ExtensionInterface) or reimplement as a Blade directive. The wrapper only makes sense in a real Symfony kernel.
• Check PHP/Symfony/Twig constraints in composer.json before extracting. If it pins Twig 2.x and you're on 3.x, the signature needs adapting; verify filter/function names so existing template call sites survive a reimplementation.
• Debugging tip: dump(parse_url($url)) (Twig {% dump %} with the debug bundle, or dd() in a Blade @php block) is usually faster than reasoning about which component you got — especially for relative URLs where host is simply absent.