- Can I use hmp/kuma-extra-bundle in a Laravel application?
- No. hmp/kuma-extra-bundle is a Symfony bundle that extends Kuma, the Kunstmaan Bundles CMS, and it has no adapter for Laravel's container, HTTP kernel, Eloquent, or Blade. Running it inside Laravel would mean hosting two full-stack frameworks to gain a few CMS conveniences. For Laravel, reimplement the needed feature natively or port non-trivial logic into an internal package.
- What does hmp/kuma-extra-bundle actually add to Kuma CMS?
- It adds practical extras on top of Kuma without patching the CMS core. That includes extra Twig extensions and template helpers, backend widgets, form types, admin tweaks, reusable services, event subscribers, and configurable defaults. The bundle is wired automatically through Symfony bundle configuration and is intended to keep Kuma projects upgrade-friendly.
- How do I install hmp/kuma-extra-bundle?
- You install it with Composer into an existing Symfony application that already runs Kuma and the Kunstmaan bundles. Then you register it in config/bundles.php and configure it through the bundle configuration. It is not installed into Laravel, and you should verify PHP, Symfony, and Kunstmaan version constraints from composer.json before requiring it.
- Which Laravel versions does hmp/kuma-extra-bundle support?
- None. This is not a Laravel package and does not target Laravel versions at all. It presumes Symfony full-stack, Doctrine, Twig, and the Kunstmaan admin stack. Check composer.json directly for its PHP, Symfony, and Kunstmaan bundle constraints.
- Does hmp/kuma-extra-bundle support Symfony 6 or Symfony 7?
- That is unverified and must be read from composer.json, not assumed from the README. The dependency matrix likely reflects the era of the originating client build, so Symfony 6 or 7 support is unlikely without confirmation. Also check the Kunstmaan bundle versions, because their Symfony LTS posture affects compatibility.
- Is hmp/kuma-extra-bundle safe for production?
- Technical risk is very high, concentrated in abandonment and dependency-graph opacity rather than proven code defects. The package has one star, zero dependents, a single agency maintainer, and unverified license, tests, and release cadence. Adopt it only inside a funded Kunstmaan application after source review and explicit ownership of the fork and patch SLA.
- How do I configure hmp/kuma-extra-bundle defaults?
- Configuration happens through the Symfony bundle configuration in a Kuma application, with defaults intended to be overridable per project. The exact keys and behavior should be read from the bundle config and src directory rather than assumed from the README. There is no Laravel config publishing path for this package.
- What are alternatives to hmp/kuma-extra-bundle for a Laravel project?
- The preferred path is to extract the required behavior as acceptance criteria and build it natively as a Laravel package or a Filament or Nova extension. If src contains genuinely non-trivial rules such as content-tree traversal or block rendering, vendor and port that logic under the license into an internal library with your own tests. Adopting the bundle itself is only valid inside an existing Kunstmaan application.
- Does hmp/kuma-extra-bundle have tests and an active maintainer?
- Tests, license, and release cadence are unverified and must be read from the repository rather than the README. The maintainer is a single agency, henrypenny, so the bus factor is one. With zero dependents, source review is the only available validation.
- What should I check before requiring hmp/kuma-extra-bundle?
- Read composer.json for PHP, Symfony, and Kunstmaan bundle constraints, then inspect the license, tests, and src directory. Confirm that the product line actually runs Kunstmaan today and name the specific admin or editor behavior you need, not the package. For a Laravel codebase, do not integrate it as a dependency.