Sulu Media Sync Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for media management (Sulu/Symfony stacks only): This bundle is a candidate "buy" for teams running Sulu CMS that need media synchronized rather than hand-rolling a custom sync layer. It is not a Laravel package in practice — it is a Symfony bundle for Sulu (composer require, bin/console doctrine:schema:update). If our product surface is Laravel-first, this does not serve that roadmap and should be logged as out-of-scope rather than evaluated further.
• Roadmap timing: At 0.1.0-beta.2 with a single vendor namespace (ahmed-bhs), this is an evaluation-only dependency. It can inform a spike or prototype behind a feature flag; it should not anchor a committed roadmap date.
• i18n/localization decisions: The release establishes English as the source language with French retained as a shipped admin UI locale. This is a useful precedent for our own packages: source language and UI locale are separate concerns, and admin-facing strings should be translatable without forking the source.
• Release/packaging hygiene as a vendor-quality signal: The maintainer disclosed that beta.1 shipped stale French sources because Packagist caches tag→commit mappings and does not follow a moved tag. That is a concrete, checkable operational fact — it tells us the maintainer debugs release plumbing and communicates it, and it gives us a pinning rule (^0.1@beta is not sufficient; pin exactly 0.1.0-beta.2 or a commit hash).
• Use cases to validate before committing: what "media sync" covers (one-way vs. bidirectional, conflict resolution, deletion propagation, large-file/batch behavior), and whether our Sulu install's media volumes and asset count are within what the bundle was tested against. The notes contain no functional changes, so none of this is answered here.

When to Consider This Package

Consider it when all of the following hold:

• The stack is genuinely Sulu CMS on Symfony, not Laravel. This is the gating criterion; treat the "Laravel/PHP package" framing as a category error for this artifact.
• Media synchronization with an external system or storage target is on the roadmap and the alternative is a multi-week custom build.
• The team accepts pre-1.0 risk: no stability guarantee, API can change between betas, and doctrine:schema:update --force implies schema-touching behavior that needs review before it runs against production.
• A named owner will read the source (it is small enough to audit) and pin an exact version or commit.
• We are comfortable with a single-maintainer dependency for a non-critical path, or can vendor/fork it.

Look elsewhere when:

• We are on Laravel and were hoping for drop-in media handling — a first-party Laravel filesystem/media package is the correct comparison, not this.
• The sync is business-critical or must run against production media without a schema-review gate.
• We need a support contract, security-response commitment, or LTS-style maintenance — none is evident at 0.1.x-beta.
• A beta.3+ release is required and we cannot verify the install actually resolves to the intended commit; the Packagist tag-caching issue means every version bump needs a clean composer.lock diff check.

How to Pitch It (Stakeholders)

For executives (one paragraph): We evaluated ahmed-bhs/sulu-media-sync-bundle, an early-beta Symfony bundle for Sulu CMS that synchronizes media. The current release, 0.1.0-beta.2, changes no behavior — it is a repackaging release that translates the source, comments, console output, README and default admin labels to English while keeping French as a selectable admin UI locale, and fixes a distribution problem where the previous beta shipped stale French sources due to Packagist's tag caching. Recommendation: do not adopt for any committed roadmap item. It is pre-1.0, single-maintainer, and only relevant if we run Sulu — which we do not on our Laravel surface. Value today is limited to a low-cost technical spike and to two reusable lessons: keep source language separate from UI locale, and pin exact versions rather than ranges for pre-1.0 dependencies.

For engineering (bullets to hand over):

• Scope check first: confirm whether we have any Sulu/Symfony footprint. If no, close as not-applicable.
• If we spike it: pin exactly 0.1.0-beta.2 or a commit hash. Do not rely on ^0.1@beta — Packagist caches tag→commit and will not follow a moved tag, which is precisely how beta.1 shipped stale sources.
• Treat php bin/console doctrine:schema:update --force as a migration, not a setup step. Review the generated SQL and move it into a proper Doctrine migration before it touches shared or production databases.
• Verify the checked-out code is English-sourced after install (read a docblock or a default admin label) as a cheap confirmation that the intended commit resolved.
• Audit the sync semantics before any integration: directionality, conflict resolution, deletion propagation, batch/large-file behavior. None of this is documented in the release notes.
• Record the risk: pre-1.0, single maintainer, no stated support or security-response process. Plan a fork-or-vendor contingency if the spike succeeds.