Media Pagepart Bundle Laravel Package

Getting Started

This bundle wires a MediaPagePart into KunstmaanPagePartBundle, letting editors drop a media item (image/video/file) into any page through the page-part picker. It is a thin, single-page-part bundle from the Symfony 2 era — install it only on a Kunstmaan CMS stack that already uses kunstmaan/pagepart-bundle and kunstmaan/media-bundle.

Minimal setup:

1. Require it (note: last tagged release is 2014, so expect old Symfony constraints):

composer require kunstmaan/media-pagepart-bundle

2. Register the bundle in AppKernel (Symfony 2/3 style, which is the only era this supports):

new Kunstmaan\MediaPagePartBundle\KunstmaanMediaPagePartBundle(),

3. Update the schema so the new page-part entity table exists, then clear caches:

bin/console doctrine:schema:update --force
bin/console cache:clear

4. Make sure the page part is registered in the page-part configuration consumed by KunstmaanPagePartBundle (look at the bundle's DependencyInjection/ and Resources/config/ for the exact service/config key in your CMS version — older setups use a pageparts section, newer Kunstmaan versions register page parts through bundle config).

Where to look first:

• Entity/MediaPagePart.php — the persisted fields (typically a Doctrine relation to Kunstmaan\MediaBundle\Entity\Media).
• Form/MediaPagePartAdminType.php — how the media picker is exposed in the admin.
• Resources/views/PagePart/MediaPagePart/view.html.twig — the frontend render template.

First use case: add a "Media" page part to a page in the admin, pick an already-uploaded item from the Media section, and confirm the frontend page template includes pagepart.defaultview for it.

Implementation Patterns

Rendering in a page template. The page part exposes a default view; the canonical pattern is to include it from your page template so you never hard-code the bundle's template path:

{% for pagepart in page.pageparts %}
    {% if pagepart.defaultview %}
        {% include pagepart.defaultview with {'pagepart': pagepart, 'page': page} %}
    {% endif %}
{% endfor %}

Guard the media and branch on type. A single media field can hold an image, video, audio, or file, so the view template usually needs to discriminate. Check the media's content type and render accordingly rather than assuming an image:

{% if pagepart.media %}
    {% if pagepart.media.contentType starts with 'image/' %}
        <img src="{{ pagepart.media.url }}" alt="{{ pagepart.media.name }}">
    {% else %}
        <a href="{{ pagepart.media.url }}">{{ pagepart.media.name }}</a>
    {% endif %}
{% endif %}

For responsive images, lean on kunstmaan/media-bundle's helpers/filters (thumbnails, image sets) rather than calling getUrl() for every breakpoint.

Override the template without forking the bundle. Copy view.html.twig into app/Resources/KunstmaanMediaPagePartBundle/views/PagePart/MediaPagePart/view.html.twig. This is the cheapest extension point and survives Composer updates.

Add caption/link/alt fields. Two viable approaches:

• Subclass the page part entity and admin type, add your columns, and register your class under the page-part name in config. Use Doctrine single-table inheritance if the base entity is mapped as a concrete entity.
• If you only need presentation logic, derive captions from the media item itself and keep the entity untouched.

Admin workflow. Editors must upload media under the Media section first; the page part's admin form only lets them select existing media. Document this in your editorial guide — "upload, then select" trips people up.

Integrate with the page-part picker. Once registered, the page part appears in the "Add page part" list on a page; its label comes from translations in the bundle. If you provide a custom admin type, confirm it is used by the registration config, not just defined as a service.

Gotchas and Tips

• Abandoned-era dependency. Last release 2014, 13 stars, no dependents. Composer resolution against Symfony 4+/PHP 8 will almost certainly fail. Check with composer why-not kunstmaan/media-pagepart-bundle before assuming it's a code bug. On a modern stack, writing your own page part (entity + AbstractPagePart subclass + admin form + Twig view) is usually faster and safer than vendoring this.
• MediaBundle coupling. The entity references the media bundle's Media class by FQCN. A namespace or schema change in a newer media bundle breaks mappings; verify doctrine:schema:validate and that the FK column exists.
• Orphaned references. There's no cascade/orphan removal from the media side. Deleting an item in the Media section can leave page parts pointing at nothing or failing an FK constraint. Add a null guard in the template ({% if pagepart.media %}) and consider a cleanup command/query for dangling media_id values.
• Blank page parts are possible. The media field may be nullable, so an editor can save a page part with no media. Always guard the render.
• Wrong template used. If your override isn't picked up, confirm it sits in the exact path the bundle's getDefaultView() returns (KunstmaanMediaPagePartBundle:PagePart/MediaPagePart:view.html.twig by convention) and clear the cache.
• "Page part not found" / missing in picker. Registration is config-driven; a service definition alone doesn't surface the page part. Re-check the pageparts config key for your Kunstmaan version and dump config (bin/console config:dump-reference kunstmaan_page_part or equivalent).
• Translations/admin labels. The bundle ships minimal translations; if the admin label is raw or missing, add the key to your app's translations rather than editing vendor files.
• Assets and cache after install. Run cache:clear and, on Symfony 2/3, assets:install --symlink so admin form assets from the media picker resolve.
• Extension points, in order of cost: template override → custom admin type → entity subclass → fork. Given the maintenance status, only subclass if you truly need persisted fields; otherwise push logic into Twig or a small renderer service.