Shorty Bundle Laravel Package

Getting Started

This is a Symfony bundle, not a Laravel package, so the first decision is whether you are maintaining a legacy Symfony 2/3 app or trying to use the underlying shortening logic from Laravel. If you are on Laravel, do not expect composer require rezzza/shorty-bundle to just work: there is no Laravel service provider, no facade, and the bundle is pinned to an old Symfony/PHP era.

Where to look first:

1. composer.json — confirm the Symfony/PHP constraints before attempting an install.
2. README.md — expected config shape and Twig/service usage.
3. DependencyInjection/Configuration.php — the authoritative list of provider options.
4. Resources/config/services.xml (or YAML) — the service ID to inject, typically the shortener service.
5. The rezzza/shorty library it wraps — provider classes and HTTP client requirements.

Minimal Symfony usage:

composer require rezzza/shorty-bundle

Register the bundle in AppKernel.php, configure a provider and credentials, then use the service:

// Symfony controller
$shortUrl = $this->get('shorty')->shorten('https://example.com/a/very/long/path?with=query');

<a href="{{ long_url|shorty }}">{{ long_url|shorty }}</a>

For Laravel, the realistic first use case is to install only the underlying rezzza/shorty library, wrap it in your own service provider/facade, or simply implement a small adapter around the provider API you actually use. Treat the bundle as a reference implementation, not a dependency.

Implementation Patterns

Wrap the shortener behind an application service. Never call the bundle service directly from many controllers or templates. Create one Shortener/LinkShortener abstraction that handles caching, validation, logging, and provider fallback. That keeps the abandoned package at the edge of your codebase.

final class LinkShortener
{
    public function __construct(
        private object $shorty,
        private CacheInterface $cache,
        private LoggerInterface $logger,
    ) {}

    public function shorten(string $url): string
    {
        $key = 'shorty:' . sha1($url);

        return $this->cache->remember($key, 86400, function () use ($url) {
            try {
                return $this->shorty->shorten($url);
            } catch (\Throwable $e) {
                $this->logger->error('Shortening failed', ['url' => $url, 'e' => $e]);
                throw $e;
            }
        });
    }
}

Cache aggressively. Short URLs are stable for a given long URL in most use cases. Store the mapping in Redis/database keyed by a hash of the long URL, and optionally store the provider and creation date. This avoids latency, rate limits, and duplicate provider calls when rendering listing pages.

Do shortening asynchronously for bulk work. If you are shortening links in emails, notifications, imports, or social posts, queue the work. A synchronous call to Bitly or another provider during a web request is a reliability and latency problem.

Use a provider fallback chain. The package era assumes one configured provider. In practice, providers change APIs or go down. Wrap two providers and try the primary, then the fallback, and log which one succeeded.

Avoid template-time API calls in loops. The Twig filter is convenient for a single link, but rendering a page with 50 links should use pre-shortened values from your model or cache, not 50 provider calls during rendering.

Laravel integration pattern. If you must use the library from Laravel, bind it as a singleton:

$this->app->singleton(LinkShortener::class, function ($app) {
    return new LinkShortener(
        // construct the rezzza/shorty client here
        $app->make(Cache::class),
        $app->make(Logger::class),
    );
});

Then expose a Blade directive or helper only if it is safe to call synchronously.

Testing pattern. Never hit the real provider in tests. Inject a fake shortener or use the underlying HTTP client’s mock handler. Assert that your service caches and that failures are logged and surfaced predictably.

Gotchas and Tips

• Abandoned and old. Last release was 2015. Expect Symfony 2/3 and PHP 5.x constraints. Composer will likely conflict with modern Laravel, Symfony 5+, and PHP 8. Check composer.json before spending time on integration.
• Symfony bundle, not Laravel package. There is no auto-discovery. Any Laravel use requires a manual port or direct use of rezzza/shorty.
• Providers may be dead. Bitly has changed API versions, and Google’s URL shortener was discontinued. Bundled provider implementations from 2015 may no longer work even if the code installs.
• Configuration keys are not obvious. Read DependencyInjection/Configuration.php rather than guessing YAML keys from blog posts. Keep credentials in environment variables, never in committed config.
• Network failures become user-facing failures. Add timeouts, retries with backoff, and a clear fallback (for example, return the original URL if shortening fails). Do not let a third-party shortener break email sending or page rendering.
• Do not shorten arbitrary user input without validation. Validate scheme/host, block internal addresses if applicable, and handle provider rejections.
• Cache negative results carefully. Repeatedly retrying a permanently invalid URL wastes quota; cache failures briefly, but do not cache transient network errors for long.
• Debugging. Log the request URL, provider name, HTTP status, and response body on failure. In Symfony, use the profiler and HTTP client events; in Laravel, use HTTP client logging around your adapter.
• Extension points. If you keep the bundle, prefer decorating your own LinkShortener service over subclassing bundle internals. If you need a new provider, implement the underlying provider interface and register it in your own service definition rather than editing vendor code.
• Template filter caution. Twig’s |shorty filter is fine for one-off admin screens, but it hides I/O in presentation. Avoid it in production listing pages and loops.