Image Bundle Laravel Package

Getting Started

This is a Symfony 2-era bundle (last tagged release March 2015) with no dependents and effectively no community. Treat it as a legacy component: viable inside an existing Symfony 2.x application, a poor choice for anything new.

Install and register

composer require ticketpark/image-bundle
# If no tag resolves against your Symfony version, pin the commit:
composer require ticketpark/image-bundle:dev-master#<commit>

Register it in app/AppKernel.php:

new Ticketpark\ImageBundle\TicketparkImageBundle(),

There is likely no routing to import for basic manipulation; check Resources/config/routing.yml before assuming otherwise.

Where to look first

1. README.md — usually the only usage documentation, and often stale relative to the code.
2. DependencyInjection/Configuration.php — the authoritative list of config keys and the config root alias (typically ticketpark_image).
3. Resources/config/services.xml (or .yml) — the real service IDs. In Symfony 2 there is no autowiring; you need the exact ID. Run php app/console container:debug | grep ticketpark to list them.
4. Tests/ — any functional tests are the best executable examples of intended usage.
5. composer.json — confirms the PHP and Symfony constraints and whether GD or Imagick is the underlying driver.

First use case: resize an uploaded avatar

// In a controller, after moving the UploadedFile
$image = $this->get('ticketpark_image.<service_from_container_debug>');
$image->load($targetPath)
      ->resize(128, 128)
      ->save($thumbPath);

Start with a single, non-critical path like avatar thumbnails. Verify output dimensions and file size before wiring it into product or media pipelines.

Implementation Patterns

Inject the service, do not grab from the container. In Symfony 2, define your controller or manager as a service and inject the image service by ID. This keeps the manipulation code testable and makes a later replacement with liip/imagine-bundle or intervention/image a one-line constructor change.

Centralize manipulation in a small application service. Wrap the bundle behind your own ImageProcessor interface:

class ImageProcessor
{
    private $imageService;
    private $cacheDir;

    public function thumbnail($source, $width, $height) { /* ... */ }
    public function crop($source, $x, $y, $w, $h) { /* ... */ }
}

This is the single most valuable pattern for an abandoned dependency: your application code never references ticketpark directly, so migration is contained.

On-demand derivative controller. A common day-to-day pattern is a route like /media/{path}?w=300&h=200 that checks a cache directory, generates the derivative if missing, and streams it. Cache the key as a hash of path + dimensions + source mtime so edits invalidate correctly.

Pre-generate in a console command. For catalogs, product images, or any set that must be warm, write a command that walks a directory or Doctrine result set and writes derivatives. This avoids the first-request latency and makes failures visible in batch logs rather than in a user's browser.

Upload pipeline ordering. Validate MIME type and extension first, move the file to a staging path, then manipulate, then persist the final path to the entity. Never manipulate the UploadedFile temp path directly if you need to retry after a failed resize.

Presets in config where supported. If Configuration.php exposes named dimensions or filter sets, use them rather than scattering magic numbers through controllers. If it does not, keep your own presets array in application config.

Testing. Use a temporary directory per test and assert on generated file dimensions via getimagesize(). Do not assert byte-for-byte output; GD and Imagick versions differ.

Gotchas and Tips

• Abandoned and unsupported. No releases since 2015, zero stars, zero dependents. No security patches, no PHP 8 compatibility work, no Symfony 4+ support. The DI container, kernel parameter names (kernel.root_dir, %kernel.cache_dir%), and templating APIs it expects are all legacy.
• Do not use on a new project. For modern Symfony, choose liip/imagine-bundle (Imagine-based, actively maintained) or intervention/image. If this bundle is already in a legacy codebase, isolate it behind your own service as above.
• Composer resolution. The 2015 tag may not satisfy modern constraint solvers. Check composer show -a ticketpark/image-bundle and be prepared to pin a commit hash rather than a version range.
• Driver requirements. Confirm whether it uses GD or Imagick from composer.json and the service definitions. GD loses EXIF orientation and has weaker alpha handling; Imagick needs the PHP extension and policy configuration. Set memory_limit high enough for the largest source image, not the largest output.
• Silent failures. Older image libraries often return false from save() rather than throwing. Check return values and verify file_exists() plus getimagesize() after every write. Log the source path and target dimensions on failure.
• Path handling is the usual bug source. Relative paths resolve against the current working directory, which differs between web requests and console commands. Always pass absolute paths built from kernel parameters.
• Cache invalidation. Derivative filenames based only on dimensions will serve stale images after a source edit. Include source mtime or a content hash in the cache key, and provide a cache-clear command.
• Permissions. The web server user and the CLI user must both be able to write the derivative directory. This surfaces as "image generates in console but 404s in the browser," or vice versa.
• Serving files through PHP is slow. If you generate derivatives on demand, consider X-Sendfile/X-Accel-Redirect or a redirect to a static path rather than reading bytes into a Symfony Response.
• Extension points. Check for tagged services or driver configuration in Resources/config/ if you need custom filters. Given the project's age and size, expect to fork rather than extend cleanly.
• Debugging. Use php app/console container:debug <service_id> to inspect arguments, and config:debug (Symfony 2.6+) to confirm your configuration root is actually being read. A misnamed root alias fails silently, leaving defaults in place.