Block Settings Bundle Laravel Package

Product Decisions This Supports

• Reducing Technical Debt: Eliminates repetitive FormMetadataVisitor boilerplate for Sulu CMS block settings, allowing PMs to advocate for cleaner, maintainable codebases.
• Accelerating Feature Delivery: Enables rapid addition of new block settings (e.g., theme, spacing, anchor) without custom visitor classes, aligning with sprint goals for CMS customization.
• De-risking the Platform Upgrade Roadmap: The 1.1.0 release adds Symfony 8 compatibility, so the "configure block settings instead of coding them" approach survives the next major framework upgrade cycle rather than becoming a migration liability. This strengthens the build-vs-buy case: a small, actively maintained dependency instead of bespoke visitor classes that must be re-audited on every Symfony major.
• Avoiding an Upgrade Blocker: Teams planning a Symfony 7 → 8 move can keep their CMS customization layer untouched, removing one line item from upgrade scope and estimation.
• Use Cases:
  • Design System Adoption: Streamlines theming/spacing controls for blocks in a headless CMS-driven design system.
  • A/B Testing: Dynamically injects experimental settings (e.g., "background variants") without code changes.
  • Multi-Tenant CMS: Centralizes block configuration across tenant-specific projects via shared XML forms.
  • Platform Modernization Programs: Lets a CMS customization layer ride along with framework upgrades instead of being rewritten in parallel.

When to Consider This Package

• Adopt if:

  • Your Sulu CMS project requires >3 custom block settings sections (e.g., theme, spacing, anchor) and you’re tired of maintaining duplicate visitor classes.
  • You prioritize configuration over code for CMS extensions (e.g., marketing teams managing settings via XML).
  • Your team uses Symfony 7.0+ or Symfony 8 with Sulu 3.0+ (PHP 8.2+ baseline; PHP 8.4+ if you are on Symfony 8).
  • You have a Symfony 8 upgrade on the roadmap and want dependencies that are already compatible rather than ones that gate the migration.
  • You need idempotent form injection (avoids duplicates across locales).

• Look Elsewhere if:

  • You’re using Sulu <3.0 or Symfony <7.0 (compatibility gap).
  • Your block settings are highly dynamic (e.g., user-generated) and require runtime logic beyond XML forms.
  • You lack XML form familiarity—this package shifts complexity to form definitions.
  • You need real-time validation or complex business logic in settings (consider a custom visitor instead).

Note: 1.1.0 is a compatibility-only release—no new configuration surface or behavior changes. Existing adopters should treat it as a low-risk patch-level bump; the decision to adopt is unchanged, but the longevity case is now stronger.

How to Pitch It (Stakeholders)

For Executives: "This package cuts the busywork of customizing Sulu CMS block settings by roughly 70%. Instead of writing 3+ boilerplate classes for every new setting (theme, spacing, etc.), our team can configure them in YAML/XML—saving dev time and reducing technical debt. For example, adding a ‘background variant’ toggle for A/B testing would take minutes instead of hours. The latest release also adds Symfony 8 support, which means this investment carries forward through our next framework upgrade instead of turning into migration work. It’s a low-risk, high-reward way to accelerate CMS customization without hiring more engineers."

For Engineering: *"The bundle replaces repetitive FormMetadataVisitor implementations with a single, configurable visitor. Key benefits:

• DRY: One visitor handles all sections (defined in config/packages/alengo_block_settings.yaml).
• Flexible: Sections are injected in order, skipping duplicates (idempotent).
• Extensible: Project-specific forms live in config/forms/—no bundle code changes needed.
• Upgrade-safe: 1.1.0 adds Symfony 8 compatibility alongside existing Symfony 7 support, so the constraint can stay open through the next major bump. No API or config changes were introduced in this release—treat it as a safe version bump. Tradeoff: Shifts some logic to XML forms, but the payoff is cleaner services.yaml and faster iteration. Ideal for projects with 3+ block settings sections, and a straightforward keep for anyone currently on the 1.x line."*