Barcode Bundle Laravel Package

Getting Started

mopa/barcode-bundle is a Symfony2 bundle, not a Laravel package. It wraps two libraries — Zend Framework 1's Zend_Barcode (1D symbologies like code128, code39, ean13, upca) and PHP QR Lib (QR codes) — and exposes them as a service, a controller endpoint, and a Twig helper that returns a URL to a generated image. For a Laravel developer the realistic day-one path is: understand the pattern (route → service → image response), then decide whether to use this bundle at all or port the idea onto maintained Laravel libraries.

Minimal setup in its native environment:

composer require mopa/barcode-bundle

// app/AppKernel.php
new Mopa\Bundle\BarcodeBundle\MopaBarcodeBundle(),

# app/config/routing.yml
mopa_barcode:
    resource: "@MopaBarcodeBundle/Resources/config/routing.xml"

Then the first use case — an invoice or shipping label:

<img src="{{ mopa_barcode_url('c128', { 'barcodeText': 'INV-1042' }) }}" alt="barcode" />
<img src="{{ mopa_barcode_url('qrcode', { 'text': 'https://example.com/o/1042' }) }}" alt="qr" />

Look first at Controller/BarcodeController.php (how the image response is built), Model/BarcodeService.php (the setType/setBarcode/getBarcode API), DependencyInjection/Configuration.php (per-type renderer and size defaults), and the Twig extension that maps the helper to a route. In Laravel, none of that wiring boots; the transferable parts are the two libraries and the URL-based rendering pattern — you would bind a service in a service provider, add Route::get('/barcode/{type}', BarcodeController::class), and return response($bytes)->header('Content-Type', 'image/png').

Implementation Patterns

URL-per-image, not inline blobs. The bundle's core pattern is a GET endpoint that streams PNG bytes. That is the right pattern to keep: <img> tags work, browsers and CDNs cache it, and your HTML stays small. Make the URL deterministic (type plus encoded payload plus options), so Cache-Control headers and an edge cache actually hit.

Route::get('/barcode/{type}/{payload}', function (string $type, string $payload) {
    $png = app(BarcodeService::class)->render($type, urldecode($payload), [
        'width' => 300, 'height' => 80, 'fontSize' => 12,
    ]);
    return response($png, 200, [
        'Content-Type' => 'image/png',
        'Cache-Control' => 'public, max-age=86400',
    ]);
})->where('payload', '.*');

Service-level usage inside controllers/jobs. Use the service directly instead of the HTTP route when you are generating PDFs, emails, or batch label sheets — you want bytes, not a URL. In the bundle the service exposes setters (setType, setBarcode) and a getter that returns the rendered output; wrap that once in your own Barcode facade so the rest of the app never touches Zend classes.

Two rendering contexts. On-screen: point at the route. In PDFs (Dompdf/wkhtmltopdf/Snappy): either give the renderer an absolute URL (url('/barcode/...')) or fetch bytes server-side and embed base64 — the latter is more reliable inside headless browsers and workers.

Per-call overrides. Keep defaults in config (renderer, width, height, font, font size) and allow query-param overrides for the odd oversized label. Do not let callers pass arbitrary options through — whitelist them in the controller.

Testing. Assert Content-Type: image/png and the PNG magic bytes (\x89PNG), plus a 200 for valid input and a 4xx for invalid symbology payloads. Do not snapshot pixel output; font and GD versions make that flaky.

Laravel equivalents worth adopting instead. picqer/php-barcode-generator (1D, SVG/PNG/HTML), endroid/qr-code or bacon/bacon-qr-code (QR, SVG incl.), simplesoftwareio/simple-qrcode (thin wrapper). These are active, PSR-4, and drop into a Laravel service provider without a Symfony kernel.

Gotchas and Tips

• This is Symfony2-era code. The bundle targets Symfony 2.x and the abandoned ZF1 Zend_Barcode; PHP QR Lib is also unmaintained. It will fight modern Composer/PHP versions and cannot be installed into a Laravel app as a bundle. Treat it as a reference implementation or a stopgap on a legacy Symfony project.
• License is NOASSERTION. The bundle's own license may be MIT, but it pulls in Zend_Barcode (BSD-3-Clause) and PHP QR Lib (LGPL-3.0) — LGPL matters if you distribute the built app. Read LICENSE and the vendored libs before shipping.
• Query parameter names differ by type. Most 1D types take barcodeText; QR takes text. Passing the wrong key is the single most common cause of a blank/error image. Hit the URL manually in a browser first, then wire the <img>.
• Payload validation is on you. ean13/upca/ean8 require exact digit lengths and valid checksums; code128 accepts full ASCII but not arbitrary binary. Zend throws renderer exceptions on bad input, and the bundle's controller may surface that as an opaque 500 — catch and log, then return a 422.
• GD and fonts. Rendering needs the GD extension and, for human-readable labels, a TrueType font path Zend can resolve. A wrong or relative font path yields labels with no text or an exception at render time, not at boot.
• QR capacity. PHP QR Lib caps around 2953 bytes at error-correction level L; long signed URLs will fail silently or produce an error image. Keep QR payloads short (IDs, not full state) and set the EC level deliberately.
• Caching is your responsibility. The endpoint is a plain GET; without Cache-Control/ETag you regenerate on every page view. Include a version/hash in the path when the payload format changes so caches invalidate cleanly.
• Debugging order: (1) request the route directly, (2) check the response Content-Type and bytes, (3) enable the framework profiler/logs to see the wrapped exception, (4) verify GD/font config.
• Extension points: override the bundle's controller route, decorate the mopa_barcode.barcode_service service, or add type mappings in the bundle config. In a Laravel port, keep the same seam: one BarcodeService interface, one route, one Blade component — swapping the underlying library later becomes a one-file change.