- Is prismic/prismic-bundle a Laravel package?
- No. It is a Symfony bundle that integrates the Prismic PHP SDK into Symfony applications through Symfony kernel/bundle registration, config.yml settings, a prismic.api container service, and Twig helpers. Laravel's service container, config repository, and Blade engine are functionally analogous but binary-incompatible with those Symfony contracts. You cannot Composer-require this package into a Laravel app and use it as designed. Treat it as a compact reference pattern, not a Laravel dependency.
- Can I install prismic/prismic-bundle directly in a Laravel application?
- Not as designed. The package expects Symfony bundle registration and Symfony service-container wiring, while Laravel has no equivalent bundle registration lifecycle. Composer may install the code, but the expected prismic.api service and configuration integration will not work without building your own Laravel bridge. For Laravel, use the official Prismic PHP SDK and wrap it in a service provider and config file.
- How do you install and configure prismic/prismic-bundle in a Symfony app?
- You register the bundle in the Symfony kernel/bundle configuration, add Prismic repository endpoint and access-token settings to the bundle config, and inject the preconfigured Prismic API service where needed. The bundle centralizes repository credentials and exposes Prismic API services through Symfony's container and autowiring. Exact configuration keys and supported Symfony versions should be verified against the archived source and README.
- Does prismic/prismic-bundle support Symfony 6, Symfony 7, or current PHP versions?
- There is no evidence of current compatibility work. The package is archived, has 8 stars, 0 dependents, and no maintainer actively tracking Symfony, PHP, Prismic API, or Prismic PHP SDK changes. Assume it is stale and test any use in an isolated branch against your exact Symfony and PHP versions. For new Laravel or Symfony work, start from the official Prismic PHP SDK instead.
- Is prismic/prismic-bundle maintained and safe for production use?
- The package is archived with 8 stars, 0 dependents, and an opportunity score of 0.27, which is the signature of an unmaintained artifact rather than a dependency. There is no maintainer to file issues against, no compatibility work for current PHP or Symfony versions, and no tracking of Prismic API or PHP SDK changes. That creates a high and asymmetric risk, including no CVE response path for compliance or LTS obligations. The blast radius is small because this is a thin wrapper, but greenlighting it means owning a fork on day one.
- Does the bundle handle Prismic previews, content releases, localization, or webhooks?
- The bundle mainly wires Prismic API clients into Symfony's service container, centralizes repository and access-token configuration, and adds Twig-side helpers for fetching and rendering content. It does not directly address preview/draft refs, content releases, localization, or webhooks beyond whatever the underlying Prismic PHP SDK and your own application code provide. Scope those capabilities against the official SDK and build explicit Laravel or Symfony handling for preview cookies, ref swapping, and release refs.
- What is the best alternative for Laravel developers who want to integrate Prismic?
- Use the official Prismic PHP SDK behind a small Laravel adapter. Add a config/prismic.php file backed by environment secrets, bind a PrismicClient wrapper as a singleton, create Blade components or a directive for slice rendering, and add a route plus middleware for preview ref handling. Inject Laravel's cache repository into the wrapper and keep Prismic-specific code behind an internal interface.
- How would I port the Symfony bundle's pattern to Laravel?
- Map each bundle concern onto a Laravel equivalent: Symfony bundle registration becomes a service provider, config.yml becomes config/prismic.php plus .env secrets, the prismic.api container service becomes a singleton binding to a PrismicClient wrapper, Twig helpers become Blade components or a @prismicSlice directive, PSR-6 or Doctrine cache injection becomes Laravel's cache repository, and preview cookie handling becomes a route plus middleware that swaps the master ref for the preview ref. The practical build is roughly one service class, one config file, a slice renderer of about 30 lines, and a preview route or middleware. Use the bundle as acceptance criteria for what the adapter must cover, not as code to depend on.
- How should we test a Laravel Prismic adapter based on this bundle's pattern?
- Do not test the archived bundle as a dependency; test your adapter against the official Prismic PHP SDK. Use a fake HTTP client or recorded Prismic responses to verify service binding, repository config, slice type-to-Blade mapping, preview ref swapping, and cache behavior. Add contract-style tests around Prismic ref semantics and preview/draft behavior so SDK or API changes are caught in your own code.
- What dependency policy and exit-cost concerns apply to prismic/prismic-bundle?
- An archived package with no maintainer and no CVE response path usually fails dependency policies for production, compliance, or LTS environments, even when the code is small. If it already exists in a Symfony install, treat the conversation as migration triage rather than package selection. Exit cost is low today because this is a thin wrapper, but it rises if bundle idioms leak into domain code. Keep Prismic behind your own interface and adopt the concepts so swapping Prismic, Contentful, Sanity, or an in-house CMS remains a contained change.