Weave Code
Url Auto Converter Bundle Laravel Package
liip/url-auto-converter-bundle
A Symfony bundle that automatically turns plain URLs in text into clickable HTML links. It provides a Twig filter and configurable URL detection, making it easy to render user-generated content with safe, consistent link markup.
[DEPRECATED] This bundle will add a Twig Extension for templates with a new filter for automatically converting urls and emails in a string to html links
Frequently asked questions about Url Auto Converter Bundle
- Can I install liip/url-auto-converter-bundle in a Laravel application?
- Not usefully, no. It is a Symfony bundle that registers a Twig extension through Symfony's dependency injection container and depends on symfony/framework-bundle and symfony/twig-bundle, so Composer resolution against a modern Laravel app on PHP 8.2+ with Symfony 6/7 components will most likely fail. The realistic path is to copy the converter class under app/Support (the MIT license permits it) and re-expose it as a Blade directive or a Str::macro.
- Does the url_auto_converter filter work with Laravel Blade templates?
- No. The filter is a Twig extension, and Twig is not Laravel's template engine. Running it inside Blade would require a Twig bridge such as rcrowe/twigbridge, which adds a second templating stack, a second escaping model, and a second maintenance liability just to get a string-filtering function. Extract the converter class and wrap it in a Blade directive instead.
- Is liip/url-auto-converter-bundle still maintained?
- The package is explicitly marked deprecated. The release before 1.3.2 dates to 2017-03-07, and the 1.3.2 notes were a bare attribution plus a PR link with no changelog. There is no fork ecosystem, no community patch stream, and only occasional single-contributor commits, so treat it as a frozen reference implementation rather than a dependency.
- What actually changed in version 1.3.2?
- The release notes contain only "thx @toooni" and a pull request link, so the only way to know is to read the diff for PR #35. If that change touched the regex set, the escaping order, or the emitted anchor attributes, any vendoring baseline or golden test files taken against the older tag are invalid. Inspect the diff before adopting or upgrading.
- Is the URL auto-conversion filter safe against XSS?
- It sits on an XSS-adjacent path because it takes untrusted strings and emits anchor markup. Two things matter: whether the converter escapes input itself or expects pre-escaped input, and whether the consuming template prints the result with a raw filter. Get that order wrong and a convenience filter becomes a stored-XSS vector, so also enforce an explicit scheme allowlist to block javascript: and data: hrefs.
- Is the regex-based converter vulnerable to ReDoS?
- There is real ReDoS exposure: the regexes date from 2017 and are applied per render over user-supplied text of unbounded length. Long pathological strings can cause heavy backtracking and tie up PHP workers. Cap input length, linkify and cache the result rather than recomputing it on every request, and benchmark long strings before shipping.
- How do I extract just the URL converter into a Laravel app?
- Copy the converter class and its regex set for URLs, www hosts, and email addresses into app/Support, keep the MIT attribution, and delete the Symfony DI service definitions and the Twig wrapper. That is on the order of a few hundred lines and roughly the only reusable part of the bundle. Re-expose it as a Blade directive, a Str::macro, or an Eloquent accessor or cast.
- What are the alternatives for auto-linking URLs in Laravel?
- The most common approach is a small custom helper that runs a scheme-allowlisted regex over text you have already escaped with e(), then emits the anchors. Maintained PHP linkifiers such as misd/linkify are also worth evaluating if you want a supported dependency. Either way, avoid pulling in a Twig bridge just to get this one filter.
- Which PHP and Symfony versions does this package require?
- The constraints were pinned to the Symfony 2.x and 3.x era, and a single-merge patch release is unlikely to have re-pinned them, so verify the published composer.json rather than assuming. Using --ignore-platform-reqs only produces an uninstallable runtime, not a working feature. Assume you need to strip the framework coupling before it can run on a current stack.
- How should I test a vendored copy of the converter?
- Write golden-file tests over a fixture set covering bare URLs, www hosts, emails, already-linked anchors, trailing punctuation, international domains, and malicious schemes like javascript: and data:. Pin the exact commit you vendored so later diffs against PR #35 remain meaningful. Also assert that escaping happens before linkification and that raw output is only used on trusted results.
Weaver
How can I help you explore Laravel packages today?