Sulu Glossary Bundle Laravel Package

Technical Evaluation

Architecture fit

• Critical framing correction: despite being filed as a "Laravel/PHP package," SuluGlossaryBundle is a Sulu 3 / Symfony bundle, not a Laravel package. There is no Laravel service provider, no Eloquent, no Blade integration. If our target stack is Laravel, architecture fit is effectively zero without an adapter layer.
• If our stack is Sulu 3 (Symfony 6/7), fit is strong and idiomatic: it follows Sulu conventions end-to-end — GlossaryEntry entity with UUIDv7, GlossaryEntryDimensionContent for draft/live per locale, admin module with security contexts, content types, resource loader, providers, SEAL indexing, HTTP cache tagging, trash handler, reference refresher.
• The dimension-content model (draft/live per locale + unlocalized type) matches Sulu's editorial workflow, so editorial and localization expectations align with native behavior rather than a bolt-on.

Integration feasibility

• Very high for an existing Sulu 3 site: it is a self-contained bundle plus a documented MySQL migration template.
• Migration tooling is the standout: sulu:glossary:migrate-from-2x and sulu:glossary:migrate-page-references target the predecessor manuxi/sulu-abbreviations-bundle 2.0, which materially lowers the cost of adopting a successor bundle.
• Optional dependency on sulu/automation-bundle for scheduled publish/unpublish is cleanly scoped — feature degrades gracefully if absent.

Technical risk

• Maturity: v1.0.0 is the first release. It carries a broad surface area (admin UI, REST, providers, SEAL, cache, Twig, commands) shipped in one go — a large blast radius for a 1.0.0.
• Bus-factor / governance: a community successor to a third-party bundle; single-maintainer and long-term-support posture are unproven. No stated LTS or deprecation policy.
• Framework coupling: Symfony/Sulu minor-version drift, Doctrine ORM behavior, and Sulu admin asset pipeline are all implicit dependencies; PHP support is pinned to 8.2–8.4.
• Infrastructure coupling: SEAL/Elasticsearch indexes (admin, website) and HTTP cache tagging are core to correctness — the package is not viable in a stripped-down deployment.
• Data migration risk: the MySQL-only migration template implies a hard assumption about the source schema; non-MySQL estates or heavily customized prior installs are exposed.

Key questions

1. Is our CMS actually Sulu 3, or is this being evaluated against a Laravel estate — and if the latter, is a headless/sidecar integration genuinely in scope?
2. Which exact Sulu and Symfony minor versions are supported, and is there a compatibility matrix beyond PHP 8.2–8.4?
3. Do we run SEAL/Elasticsearch and a tag-aware HTTP cache? If not, what degrades?
4. What locales and translation workflows are in scope (copy-to-locale, translation restore), and does the dimension-content model match our editorial governance?
5. Who owns upstream maintenance, what is the release cadence, license, and security disclosure process?
6. Does the 2.x migration command cover customized legacy schemas, or only stock sulu-abbreviations-bundle installs?
7. Is type (abbreviation/acronym/term) sufficient taxonomy, or will we need extension points — and are the entities designed for extension?

Integration Approach

Stack fit

• Target runtime: PHP 8.2–8.4, Symfony + Sulu 3, Doctrine ORM, Sulu Admin (React), Twig front end, SEAL/Elasticsearch, tag-based HTTP cache.
• Not a Laravel fit. In a Laravel estate the only realistic paths are (a) reject, (b) run Sulu as a separate CMS application and consume content headlessly — but note the shipped REST controllers are Sulu admin endpoints with #[Route] attributes, not a documented public content API — or (c) reimplement the glossary domain in Laravel. All three are materially more expensive than the package implies.
• Twig surface (sulu_resolve_glossary_entry, sulu_get_glossary_entries, load_glossary_settings, optional abbr filter) means front-end rendering assumptions live in Twig; a Laravel/Blade front end would need a translation layer.

Migration path

• From manuxi/sulu-abbreviations-bundle 2.0: run sulu:glossary:migrate-from-2x, then sulu:glossary:migrate-page-references to repoint page content references.
• Apply docs/templates/doctrine-migration.php.dist for MySQL schema changes; treat as a template requiring review, not a black box.
• Mandatory: full DB + media backup, staging rehearsal on an anonymized production copy, and a verified rollback (schema down-migration or snapshot restore).

Compatibility

• Confirm Sulu 3 minor and Symfony version support explicitly with upstream before committing.
• SEAL indexes admin and website must exist and be reindexable.
• sulu/automation-bundle is required only for scheduled publishing; if we need it, our scheduler/worker must already be operational.
• Config knobs to set deliberately at install: sulu_glossary.versioning.max_versions (20 default, 0 = unlimited — avoid 0 in production) and sulu_glossary.twig.auto_abbr.

Sequencing

1. Spike in a disposable Sulu 3 environment: install bundle, verify admin module, security contexts sulu.glossary.entries / sulu.glossary.settings, and content types render.
2. Validate SEAL reindex and cache invalidation behavior on content change.
3. Rehearse migration against a production data copy; measure runtime and diff entry counts, translations, and page references.
4. Wire templates to glossary_entry_selection, single_glossary_entry_selection, and the resource loader; confirm smart content, teaser, link, sitemap, preview, and route defaults (glossary_entries).
5. Configure roles/permissions and editorial workflow (publish, unpublish, remove draft, copy to locale, delete/restore translation, version restore).
6. Staged production cutover behind a maintenance window, followed by index rebuild, cache warm, and a smoke pass on glossary routes and sitemap.

Operational Impact

Maintenance

• Pin to an exact version and review upstream releases; a 1.0.0 community bundle should be treated as fast-moving for the first several minors.
• Budget recurring effort for Sulu/Symfony upgrade tracking — the bundle sits deep in the content model, so framework majors will require coordinated upgrades.
• Version limit and trash/version-restore features mean glossary data will grow; monitor table size and prune per policy.

Support

• Documentation ships in English and German; quality signals are good (unit + functional tests, PHPStan level 6, PHP CS Fixer, CI across PHP 8.2–8.4).
• No commercial SLA or vendor escalation path. Support is community/upstream issues. We should designate an internal owner with Sulu 3 depth and a fork-and-patch capability as contingency.

Scaling

• SEAL reindex on every content change is the primary scaling consideration: batch editorial activity (bulk imports, mass translations) will generate index write amplification. Plan index capacity and throttle bulk operations.
• HTTP cache tagging and invalidation are assets here — glossary edits invalidate narrowly rather than flushing whole pages, which protects origin load.
• max_versions default of 20 caps unbounded version growth; explicitly set it rather than relying on defaults.

Failure modes

• Index desync: glossary entries present in admin but stale/absent on the website index — symptom is missing or outdated glossary output after publish.
• Cache staleness: entries update but pages serve cached content if tag invalidation is misconfigured or a reverse proxy ignores tags.
• Migration failure mid-run: partially migrated abbreviations with broken page references; the paired migrate-page-references command suggests reference integrity is the fragile step.
• Locale/translation corruption: copy-to-locale and translation restore are stateful operations; incorrect usage can propagate draft content or resurrect deleted translations.
• Scheduled publishing silently inert: if sulu/automation-bundle is absent or its worker is down, unpublished/published transitions never fire.
• Editorial misuse of type: unlocalized taxonomy means a mis-set type is global across locales.

Ramp-up

• Editors: moderate. New admin section, glossary list/form, draft-vs-live mental model, copy-to-locale, version restore, and the abbr filter behavior all need a short training pass and a style guide for when to use abbreviation vs acronym vs term.
• Developers: moderate-to-high. Requires comfort with Sulu 3 dimension content, content types, resource loaders, providers, SEAL, and Symfony cache tagging — not transferable from Laravel experience.
• Estimate: ~1–2 days engineering spike for a Sulu-fluent developer; ~1 week for a Laravel-fluent developer just to evaluate viability. Editorial onboarding ~1 hour plus a written runbook.
• Go/no-go recommendation: viable and attractive only on an existing Sulu 3/MySQL/SEAL estate with a 2.x abbreviations bundle to migrate. On any other stack — and specifically Laravel — recommend declining this release and revisiting only if a supported headless content API or adapter emerges.