Admin Gallery Bundle Laravel Package

Getting Started

This bundle is glue code: it wires fsi/gallery-bundle entities into the FSiAdminBundle admin UI. It ships no entities of its own — it registers admin controllers, routes, and template mappings so that galleries and gallery items become CRUD screens inside /admin.

Before you do anything, check your stack. Last release was 2015-03-10, there are no dependents and no stars, so treat this as a legacy component of an already-existing Symfony 2.x/3.x project rather than a greenfield dependency.

Minimal steps:

1. composer require fsi/admin-gallery-bundle (you will almost certainly need to pin to a dev-*/legacy tag; check what fsi/gallery-bundle version your app already resolves).
2. Register the bundle after both of its dependencies in AppKernel/bundles.php:
   • FSi\Bundle\AdminBundle\FSiAdminBundle
   • FSi\Bundle\GalleryBundle\FSiGalleryBundle
   • FSi\Bundle\AdminGalleryBundle\FSiAdminGalleryBundle
3. Import its routing from your admin routing file (look under Resources/config/routing.yml — the file name/route prefix may differ by release).
4. Log into the admin panel as a user with the FSi admin role and confirm you see Gallery / Gallery Item entries in the navigation.

Where to look first: the Admin/ (or Controller/) directory for the admin classes it registers, then DependencyInjection/ for config keys, then Resources/views/ for what you can override. In a package this thin, reading all of it takes ten minutes and pays for itself.

First use case: create a gallery, upload a couple of images as items, then render that gallery on the frontend using fsi/gallery-bundle's services — not this bundle's. This bundle is admin-only.

Implementation Patterns

The bundle's job is declarative: it points FSiAdminBundle at gallery entities and supplies default admin metadata. Your day-to-day work happens in three places:

1. Overriding the default admin definition. If you need to hide a field, rename a label, or change a datagrid column, subclass the admin class the bundle registers and re-register your subclass with the same service id (or use the bundle's config to swap the class, if exposed). Copy the original definition first — the service ids are your reference point.

2. Template overrides. Use Symfony's bundle override convention for your version: app/Resources/FSiAdminGalleryBundle/views/... on older Symfony, or templates/bundles/FSiAdminGalleryBundle/... on newer. This is where you customise the item form, thumbnail rendering, and batch-action markup.

3. Frontend rendering. Once galleries are created through the admin, use fsi/gallery-bundle directly in your controllers/templates: fetch a gallery by its identifier, iterate its items, resolve image URLs. Do not route frontend rendering through this bundle.

Typical workflow: install → import routes → log in → create a gallery → add items → attach the gallery identifier to whatever CMS page/content entity you already have → render via gallery-bundle services.

Integration tip: if you have a custom content type that owns galleries, add the relation on your side (a gallery property or a galleryId field) rather than modifying anything in this bundle. It is much cheaper to keep the bundle pristine than to patch a ten-year-old dependency.

Gotchas and Tips

• Abandoned upstream. Last release 2015, zero dependents, zero stars. There is no community, no issue triage, and no chance a fix will land. Budget for reading the source and forking if you need changes.
• Version skew is the main failure mode. The bundle's composer.json targets old Symfony and old fsi/gallery-bundle lines. If composer require solves to something incompatible with your app, stop — do not force it. Fork, relax constraints, and vendor it.
• Route name collisions. Importing the routing file twice (e.g. once in routing_dev.yml and once in the main file) will produce duplicate route names. Use debug:router to check what's actually registered.
• Service ids are undocumented. Use debug:container --tag=... and grep DependencyInjection/ for admin/gallery aliases. There is no reference documentation — the DI extension is the documentation.
• Bundle load order matters. If FSiAdminBundle loads after this one, its admin registry may miss the gallery definitions and you will get empty nav entries with no error. Reorder in AppKernel before debugging anything else.
• Template override path changed with Symfony versions. The two conventions are not interchangeable; use the one matching your kernel version or the override silently does nothing.
• No config validation edge cases. Because the tree is small, a misspelled config key is often silently ignored rather than throwing. When something "doesn't work," dump the processed config (debug:config or the config.yml in the profiler) before writing any code.
• Extension point: the cleanest way to inject custom behaviour is a compiler pass that decorates the registered admin service, rather than modifying the bundle in place. This survives a fork of the repository and keeps the original definitions readable.
• Recommendation: if this package is new to the project, don't adopt it. Fork it into src/, drop the abandoned dependency metadata, and treat it as project code — that is effectively what it is at this point.