Pumukit Expired Video Bundle Laravel Package

Getting Started

This is a single-purpose Pumukit bundle (Pumukit is Teltek's Symfony/MongoDB video platform), so treat it as a small extension rather than a framework: expect one or two console commands plus a service or two, not a full admin suite.

Minimal steps:

1. Install into the same app as Pumukit — it depends on pumukit/core-bundle (or equivalent Pumukit core packages) and MongoDB ODM documents. There is no standalone usage; it must live alongside a running Pumukit instance.

   composer require teltek/pumukit-expired-video-bundle
   

2. Register the bundle in the kernel (Pumukit 2.x/3.x style):

   // app/AppKernel.php
   new Teltek\PumukitExpiredVideoBundle\PumukitExpiredVideoBundle(),
   

3. Read the source before configuring. With ~1 star and 0 dependents, docs are sparse. In order, check:
   • Command/ — the actual entry points and their names/arguments (e.g. a ...ExpiredVideo...Command).
   • DependencyInjection/Configuration.php — the real config tree keys.
   • Resources/config/services.yml — which Pumukit services it decorates or consumes.
   • README.md — likely one paragraph and a sample command invocation.
4. First use case: run the command in dry-run if it supports one, against a staging database. If not, back up / snapshot the Mongo DB first and run it on a single test series.

   php app/console list | grep -i expired
   php app/console <command-name> --help
   

The typical job it exists for: find MultimediaObjects or Series whose publication window has passed and either unpublish, archive, or delete them, on a schedule.

Implementation Patterns

Cron-driven housekeeping. The intended pattern is almost certainly a scheduled command, not a request-time hook:

0 3 * * * cd /var/www/pumukit && php app/console <expired-command> --env=prod >> var/log/expired.log 2>&1

Wrap it in a shell script with a lock (flock) so overlapping runs can't double-process the same objects.

Two-phase: mark, then purge. Don't go straight to deletion. Use the bundle's selection logic to tag the matching objects (via a Pumukit Tag, e.g. expired-candidate), have an editor review them in the admin UI, then run the destructive pass over tagged objects only. If the bundle doesn't expose a "mark" mode, add a thin wrapper command in your app that queries the same criteria and applies the tag.

Compose with Pumukit's own tooling. Rather than reimplementing rules, derive expiration from existing metadata:

• MultimediaObject::$publicDate / $recordDate for age-based windows.
• Series for series-wide expiry (expire the series, not the orphaned chapters).
• Tags for per-collection retention (e.g. keep-forever, faculty-archive).
• Playlist/Broadcast references — check whether the object is still published anywhere before removing it.

Service decoration. If you need to change when a video counts as expired without forking, decorate the bundle's service in your app's services.yml:

app.expired_video.policy:
    decorates: teltek.pumukit_expired_video.<service_id>
    class: AppBundle\ExpiredVideo\CustomPolicy
    arguments: ['@app.expired_video.policy.inner']

Confirm the actual service id in Resources/config/services.yml first.

Event hooks over cron for small sets. For "unpublish immediately when the date passes" behavior, listen on Pumukit's multimedia events plus a lightweight periodic sweep, rather than a once-a-day cron. Keep the heavy purge on cron.

Multi-instance safety. In a load-balanced Pumukit deploy, run the command on exactly one node (a dedicated worker role) or gate it behind flock/a Mongo lock document. Two crons racing on the same objects is the classic failure mode here.

Report before acting. Have the command emit counts (matched / unpublished / deleted / skipped) to stdout or a log channel; feed those into your monitoring so a sudden zero or spike is visible.

Gotchas and Tips

• Abandoned/low-maintenance risk. 1 star, 0 dependents means no upstream safety net. Pin the version in composer.json and vendor the relevant command logic into your app if it's more than a few dozen lines — you will end up maintaining it.
• Pumukit/Symfony version trap. Pumukit has moved from Symfony 2/3 (AppKernel) to Symfony 4+/5 (config/bundles.php). Check the bundle's composer.json require block against your Pumukit version before installing; a mismatch usually surfaces as a container compile error, not a clear message.
• Deletion is not clean deletion. Pumukit objects are referenced by Series, Playlist, Broadcast, tags, and persons. Removing a MultimediaObject without detaching references leaves dangling ids that break admin lists. Verify what the bundle does — and whether it removes the underlying media files/tracks, which is a separate concern from the Mongo document.
• Mongo has no transactions across documents in older Pumukit deployments. A crash mid-purge leaves partial state; make the operation idempotent and re-runnable.
• No dry-run? Add one. It's a 10-line guard around the delete call and it's the single highest-value improvement you can make to this bundle.
• Config quirks. Pumukit bundles often read from parameters.yml in addition to bundle config, and some settings are baked into pumukit.yml. If a config key seems ignored, grep the bundle source for getParameter — the documented location may not be the effective one.
• Permissions. Console commands touching media files need the same filesystem user as the web app (www-data), or you'll get readable-in-admin but 404-on-playback objects.
• Timezones. Expiration comparisons on \DateTime are a common source of "expired a day early/late" bugs. Confirm whether the bundle compares in the app timezone or UTC, and set date_default_timezone explicitly in the cron environment.
• Extension points. If you need custom behavior, the least-fragile options in order: (1) decorate a service, (2) subclass the command in your own bundle with a higher-priority name, (3) fork. Avoid editing vendor files.
• Debugging. Use php app/console debug:container | grep expired to see what's actually registered, and -vvv on the command to surface ODM query errors. Enable the Doctrine ODM query logger if you need to see exactly which documents match.