- Can I use rokka/client-bundle in a Laravel application?
- No. This is a Symfony bundle that registers DI services, a configuration tree, and autowiring aliases inside Symfony's kernel, and Laravel has no concept of bundles or extension classes. The package cannot be installed into a Laravel app as delivered. For Laravel you should depend on the underlying rokka/client SDK directly and hand-roll a service provider, a config/rokka.php file, and optionally a facade.
- How do I install and configure rokka/client-bundle in Symfony?
- Require it with Composer, then add a configuration block under config/packages (typically rokka.yaml) and inject the Rokka services via autowiring. The bundle exposes Rokka\Client services and Twig helpers for generating dynamic image URLs and stack-based transformations. Setup is usually a day or less on a Symfony 5, 6, or 7 application. Check the bundle's composer.json for the exact PHP and Symfony version constraints before committing.
- What Laravel version does rokka/client-bundle support?
- None. The bundle targets Symfony and has no Laravel service provider, facade, or Blade integration. There is no Laravel version compatibility to evaluate because the package is never loaded by Laravel's container. If you need Rokka in Laravel, evaluate rokka/client instead and treat this repo as reference documentation for how to wire the SDK.
- How do I generate Rokka image URLs in Laravel?
- Use the rokka/client SDK to build stack URLs and wrap that in your own helper class, facade, or Blade directive. The bundle's Twig helpers are Symfony-specific and will not work in Laravel. Keep URL generation and transform presets in a single ImageService adapter so frontend conventions stay consistent. Align transform presets with your design team before rolling out.
- What is the difference between rokka/client-bundle and rokka/client?
- The bundle is a thin Symfony integration layer that wires configuration, DI services, and Twig helpers around the SDK. rokka/client is the actual SDK that handles signing, uploads, URL generation, and stack management. The functionally important code lives in the SDK, so on Laravel you only need rokka/client. This repository is effectively a convenience wrapper for Symfony projects.
- Is rokka/client-bundle actively maintained?
- The last release was January 2024, with roughly 8 stars and 0 dependents, so there is essentially no community validation or third-party battle-testing. The code surface is small and MIT-licensed, which limits code risk, but it is effectively a single-vendor artifact. Verify the release cadence tracks current Symfony and PHP majors before adopting it, and read the service definitions yourself.
- How do I test a Rokka integration without hitting the live CDN?
- Keep all Rokka logic behind an internal ImageService interface and bind a fake or no-op implementation in your test container. In Symfony you can swap the client service, and in Laravel you can bind a fake in the service provider. Using a PSR-18 HTTP client abstraction also lets you mock transport-level responses. Test URL generation and stack naming deterministically without network calls.
- What are alternatives to rokka/client-bundle for image transformations in Laravel?
- For Rokka specifically, use rokka/client directly behind your own service provider. For general image handling, developers commonly compare Glide, Intervention Image, imgproxy, and Cloudinary. Rokka's differentiators are stacks, dynamic metadata, and on-the-fly operations via its CDN. If you only need resize and format conversion, a cheaper or self-hosted option may cover the requirement.
- How should I handle Rokka API credentials in production?
- Store the API key and organization in environment variables or your platform's secret store, never in committed config files. In Symfony, reference env vars from the bundle config; in Laravel, read them in config/rokka.php via env(). Restrict key permissions, rotate credentials periodically, and never expose the private key to the browser. Also confirm data residency, since Rokka is Swiss-hosted.
- What is the migration path if we adopt Rokka and later switch image CDNs?
- Put Rokka behind an internal ImageService interface from day one and keep URL generation, signing, and transform presets inside that adapter. If you later move frameworks, the Symfony bundle is discarded but your SDK usage and adapter survive. Document the exit path and the vendor-neutral interface before rollout, and roll out behind a feature flag to measure cache hit rate and latency. Rokka is a commercial CDN, so treat adoption as a procurement and lock-in decision, not just a library choice.