Weave Code
Rokka Imagine Bundle Laravel Package
liip/rokka-imagine-bundle
Symfony bundle integrating LiipImagineBundle with Rokka, so image transformations and delivery run through Rokka’s image CDN. Configure Rokka as the Imagine loader/cache to serve optimized, responsive images without local processing.
This bundle provides an integration between ImagineBundle and Rokka service.
Frequently asked questions about Rokka Imagine Bundle
- What is liip/rokka-imagine-bundle used for?
- It is a thin Symfony bundle that registers Rokka-backed implementations of LiipImagineBundle's data loader and cache resolver, so image transformations and delivery run through Rokka's image CDN instead of local processing. In practice you keep your existing Imagine filter sets and cache configuration while originals are pushed to Rokka and served back as Rokka stacks. It is glue between two third-party products, not a standalone image platform. If you are not already on Symfony with LiipImagineBundle and a Rokka contract, it adds no value.
- Can I use liip/rokka-imagine-bundle in a Laravel app?
- No. This is a Symfony bundle only: it ships no Laravel service provider, config publishing, or facade, and it depends on LiipImagineBundle, which is itself Symfony-oriented. Laravel image workflows such as Glide, Intervention Image, or Spatie Media Library conversions have no extension points this bundle can hook into. If you want Rokka in Laravel, treat the package as MIT-licensed reference and reimplement its roughly 300 lines of glue against the current rokka/client and your own image abstraction.
- Which Symfony and PHP versions does liip/rokka-imagine-bundle support?
- Release 1.2.0 adds Symfony 5 support, so the package now installs on Symfony 5.x, but the ceiling is Symfony 5 and there is nothing for Symfony 6 or 7. Symfony 5.4, the final LTS of that line, is past end of security support, so the newly supported branch is not a good place to start new work. The 1.2.0 note does not disclose PHP or dependency bumps, so read composer.json before trusting the constraint. Treat the Symfony 5 claim as unverified until you have seen a CI run against it.
- How do I install and configure liip/rokka-imagine-bundle?
- Install with Composer, register the bundle in your Symfony kernel or bundles.php, then supply your Rokka credentials and stack settings through bundle configuration. After that, point LiipImagine's data loader and cache resolver at the Rokka-backed services so cache resolve commands push originals to Rokka and return CDN-served stacks. Because the repository is archived with only a single 1.2.0 tag, vendor or fork the code you install so you control patches. Verify the install against your exact Symfony and LiipImagineBundle versions instead of relying on the tag's compatibility claim.
- Do I need a Rokka account, API key, and image stack to use it?
- Yes. Rokka is a commercial image-processing CDN, so the bundle is useless without a signed Rokka contract, an API key, and at least one configured image stack. The bundle only provides the adapter layer; storage, transformation, and delivery all happen on Rokka infrastructure. Budget and data-residency reviews should happen before you wire anything in, because the package cannot fall back to local processing on its own.
- Does it work with existing LiipImagineBundle filter sets and cache configuration?
- Yes, that is exactly what it is for. It supplies a Rokka data loader for resolving source images and a cache resolver backed by Rokka image stacks, so existing filter sets, filter names, and cache configuration keep working while the heavy lifting moves to the CDN. Filters that map cleanly onto Rokka stack operations behave predictably; anything relying on Imagine-only runtime behavior can drift. Test each filter you depend on, because the adapter translates filters rather than executing them.
- How do the Rokka data loader and cache resolver actually work?
- The data loader resolves a source image reference into something Rokka can accept, uploading the original when needed. The cache resolver then answers LiipImagine cache lookups with a Rokka stack URL instead of a locally generated file, which is why liip:imagine:cache:resolve results become CDN URLs. Because this is glue over a remote service, stack option changes, signing changes, or metadata format changes on Rokka's side can alter behavior with no code change in your application. Keep an integration test that asserts the returned URL and headers.
- Is liip/rokka-imagine-bundle maintained and safe for production?
- Treat it as high risk. The repository appears archived, maintenance is a single 1.2.0 tag rather than a cadence, and there are no dependents or advisory history to borrow confidence from, so no visible security response path exists. A one-line release note claiming Symfony 5 support that may be only a composer.json change can turn a clean install-time error into a runtime error. Only run it as a vendored or forked copy you own, and plan to rewrite rather than wait for fixes.
- How do I test a Rokka-backed LiipImagine setup?
- There are no first-class test doubles documented, so test at the seams you control. Fake the LiipImagine loader and cache resolver interfaces in unit tests to assert that your filter sets request the right stack and options, and run a small integration suite against a dedicated Rokka organization or stack to catch URL, signing, and metadata drift. Assert on the returned stack URL and on failure modes such as missing images or bad credentials rather than on pixel output. Keep that suite running even after you fork, since it is your only early warning for upstream changes.
- How do I replace this bundle on Symfony 6 or 7, or move to another image CDN?
- On Symfony 6 or 7 you cannot adopt this package, so reimplement its roughly 300 lines of glue against current rokka/client and current LiipImagineBundle extension points, using the MIT-licensed source as documentation. If you are reconsidering the abstraction, define an internal ImageTransformer port and let Rokka, Cloudinary, imgix, or self-hosted Thumbor sit behind it as adapters, which turns cost and data-residency comparisons into a configuration decision instead of a rewrite. For a Symfony 5.4 stopgap, install a forked copy you control and pin it. Either way, do not let an archived package become an unreviewed permanent dependency.
Weaver
How can I help you explore Laravel packages today?