- How do I migrate from manual FormMetadataVisitor classes to this bundle?
- Start by auditing your existing visitor classes (e.g., `BlockSettingsThemeFormMetadataVisitor`). Replace each with a YAML entry in `alengo_block_settings.yaml` under the `sections` key, referencing the corresponding XML form key. Test incrementally by replacing one visitor at a time, then remove the old service definitions from `config/services.yaml`. Always verify form rendering and validation post-migration.
- Does this bundle support multi-locale Sulu projects without duplicating forms?
- Yes, the bundle is idempotent by design—it skips sections already present across locales, preventing duplication. However, ensure your XML forms are locale-agnostic or explicitly handle translations in the form definitions themselves. Test in a multi-locale environment to confirm behavior matches expectations.
- What happens if an XML form referenced in the config is missing?
- The bundle will silently skip the missing form during injection, but this may cause runtime errors if the form is required for block functionality. Always validate that all XML forms exist in `config/forms/` before enabling the bundle. Use `sulu:debug:form-metadata` to inspect loaded forms and catch issues early.
- Can I conditionally inject sections based on block type or other logic?
- No, the bundle currently supports static section injection via YAML configuration. Conditional logic would require extending the `BlockSettingsFormMetadataVisitor` class or creating a custom visitor that integrates with the bundle’s workflow. This would involve overriding the `visitFormMetadata` method and adding your own conditions.
- What’s the performance impact of loading multiple XML forms per block edit?
- The bundle loads all configured XML forms once per request and caches them, so the overhead scales linearly with the number of sections. For most projects, this is negligible unless you have hundreds of forms. Monitor Symfony’s profiler during block edits to measure real-world impact, especially in high-traffic Sulu admin environments.
- How does validation work for forms injected by this bundle?
- Validation errors from injected forms are surfaced to users the same way as native Sulu forms—through Symfony’s validation system and Sulu’s admin UI. The bundle doesn’t alter validation behavior; it merely appends form sections to the existing `content_block_settings` form. Test validation in a staging environment to ensure errors display correctly.
- Is this bundle compatible with Sulu 2.x or older Symfony versions?
- No, the bundle requires **Sulu 3.0+** and **Symfony 7.0+** due to dependencies on modern Sulu APIs and Symfony’s form system. Legacy projects would need significant refactoring to upgrade, and the bundle isn’t designed for backward compatibility. Check the [repository](https://github.com/alengodev/SuluBlockSettingsBundle) for potential future support.
- What if I have conflicting priorities with existing FormMetadataVisitor services?
- The bundle defaults to a priority of `-10`, which may clash with other visitors. Test thoroughly in a staging environment to ensure sections render in the correct order. Adjust the `priority` in `alengo_block_settings.yaml` if needed, but be aware that lower values (more negative) execute later in the chain.
- Are there alternatives for dynamic block settings in Sulu without this bundle?
- Yes, you can manually implement `FormMetadataVisitorInterface` for each section, as Sulu’s core system allows. However, this requires writing boilerplate visitor classes and managing service priorities. Other bundles like `SuluFormBundle` or custom solutions using Symfony’s form extensions may also work, but none offer the declarative YAML-driven approach of this bundle.
- How do I debug issues with injected forms not appearing in the Sulu admin?
- Start by checking `var/log/dev.log` for `FormMetadataVisitor` exceptions. Use the `sulu:debug:form-metadata` command to inspect the final form structure and verify your sections are loaded. Ensure the XML forms exist in `config/forms/` and their keys match those in `alengo_block_settings.yaml`. If forms load but don’t render, inspect the Sulu admin’s browser console for JavaScript errors.