Cms Media Bundle Laravel Package

Getting Started

Reality check before anything else. presta/cms-media-bundle is a Symfony 2.x bundle for PrestaCMS (Symfony CMF + Sonata Admin), last released 2014-02-26 and archived. It has no Laravel service provider, no illuminate/* compatibility, and its composer constraints (symfony/* ~2.3, PHP 5.x) will conflict immediately with any modern Laravel app. composer require presta/cms-media-bundle in a Laravel project is a dead end — expect a dependency-resolution wall, not a working install.

That leaves two realistic entry points:

1. Legacy Symfony app path — the bundle's intended home. You have a PrestaCMS site on Symfony 2.3/2.4 and need media blocks back in service.
2. Reference-implementation path — the far more common case for a Laravel team. You read the bundle as a ~small design spec for "media blocks + CKEditor media picker" and rebuild it in Laravel in a weekend. Given 8 stars, 0 dependents, and no tests, this is the honest recommendation.

Where to look first, in order:

• Block/ — the block classes are the product. Everything else is wiring.
• Resources/config/services.yml and DependencyInjection/Configuration.php — service ids and the config keys you'll actually set.
• Entity/ — the media model and how a block references it (almost certainly by id, not by embedded object).
• Resources/views/Block/ — Twig rendering of each block type.
• Resources/public/ — the CKEditor plugin (JS + icons) that opens the media browser.

First use case to validate the install: add a "Media" block to a CMS page that renders one image/video/file with caption and alignment, and click the CKEditor toolbar button to insert an existing media item into rich text by id. If both work, the rest is template polish. Minimum legacy steps: require the bundle, register it in AppKernel after the bundles it depends on (Sonata Admin, the block/CMF bundle, CKEditor bundle, and whatever supplies the media entity), register its admin, run assets:install --symlink, then expose the block in the PrestaCMS block configuration and page-editor picker.

Implementation Patterns

Block-registration over subclassing. Media blocks are declared through configuration and resolved by a block factory keyed on service ids. The durable pattern is: add the block to the config array, override only its Twig template. Subclassing a block class is fragile because the factory and the admin form type both assume the original id.

Id-reference, resolve-at-render. The single most reusable idea in this package: a block stores a media id plus display options (caption, alignment, size, link), and the template resolves that id to an entity via a helper/Twig function at render time. Never serialize the file path or the entity into block content — it breaks on file replacement, storage migration, and CDN moves.

Template override as the customization seam. Overrides live at app/Resources/PrestaCMSMediaBundle/views/Block/*.html.twig. Do all presentation work there; keep the block class and form type stock so upgrades (such as they are) don't fight you.

Token-in-rich-text, not raw HTML. The CKEditor plugin inserts a media reference into the editor payload (an id-bearing element or placeholder token), and a filter/renderer resolves it server-side. Copy this contract verbatim in Laravel — it stops editors from pasting <img src="/uploads/..."> directly into copy, which is the usual source of broken images after a storage change.

End-to-end workflow to mirror:

1. Editor inserts a Media block on a page (or clicks the CKEditor button).
2. Block form / media browser selects an existing media item + options.
3. Block persisted with media_id and option payload.
4. Front controller renders the block template.
5. Template asks a resolver for URL/thumbnail/metadata; caching layer wraps step 5.

Laravel rebuild mapping if you go the port route:

Gotchas and Tips

• Archived means no patching. Feb 2014 last release, MIT, 8 stars, 0 dependents. Fine as a reference; unacceptable as a dependency on anything public-facing or long-lived.
• Hard platform ceiling. PHP ~5.3–5.6 and Symfony 2.x. It will not install on PHP 8 or Symfony 4+, so even a "separate Symfony app behind HTTP" plan means running an EOL stack. Budget for that or don't do it.
• Bundle enable-order is load-bearing. The bundle leans on Sonata Admin, a media storage bundle, the CMF block bundle, and a CKEditor bundle. Registering it before its dependencies produces opaque "service not found" / "cannot autowire" errors rather than a useful message. Enable order, then cache:clear after every config edit.
• Silent CKEditor button. The plugin assets live in Resources/public; without assets:install --symlink (or with a wrong web root) the toolbar button simply doesn't appear. Also verify the editor's extraPlugins / toolbars config actually includes it — it registers as a plugin but is not always added to the toolbar by default.
• Broken thumbnails are usually not this bundle. Upload dirs, filesystem abstraction, and thumbnail filters belong to the media-storage bundle (or LiipImagine). Check that config before debugging media block code.
• Treat the source as the spec. No tests, thin docs. Grep for service ids and getBlockPrefix/getName to find each block's form type, template, and admin registration — that chain is the real documentation.
• Extension points, ranked by safety: Twig template override → block config array → form type override in app/config → subclassing (avoid).
• Decision rule for a Laravel team: if the requirement is "let editors drop images/video into pages," the media-library + block-builder rebuild is faster than the Symfony 2 archaeology and gets you maintained dependencies. Take the ideas — id-reference storage, token insertion from CKEditor, template-level presentation overrides — and leave the code behind.