Pumukit Podcast Bundle Laravel Package

Getting Started

This bundle plugs podcast ingest/export into a PuMuKIT installation. It is not a standalone library — it assumes a working PuMuKIT app (Symfony) with Pumukit\MultimediaObjectBundle, Pumukit\SeriesBundle, and Pumukit\SchemaBundle already installed. Treat it as an integration layer, not a library you can evaluate in isolation.

Minimal steps:

1. Read the repo structure before composer.json. At 1 star and 0 dependents, treat the code itself as the documentation. Check Resources/config/, Command/, and DependencyInjection/ first — those three tell you what the bundle actually does (services, CLI entrypoints, and config keys).
2. Match the PuMuKIT version. Look at the pumukit/* constraints in composer.json and pin the same major/minor as your PuMuKIT install. A PodcastBundle from a different PuMuKIT generation will silently break on entity/schema changes.
3. Register the bundle the Symfony way for your PuMuKIT version (legacy AppKernel.php for older installs, config/bundles.php for newer).
4. Run the migrations / schema update — the bundle likely adds podcast-related fields or tables to Series/MultimediaObject.
5. First use case: import a single podcast feed and confirm it lands as a Series with episodes as MultimediaObjects. Start there before touching export/RSS generation, because import exercises most of the bundle's wiring.

If you can't get a feed import running in an afternoon on a stock PuMuKIT VM, stop — the bundle is not a fit and you should fork the podcast logic directly into your app instead.

Implementation Patterns

The realistic day-to-day patterns:

• Ingest via command, not via UI. PuMuKIT bundles typically expose Symfony console commands (podcast:import:* style). Wire the import to a cron/worker rather than a web request — feed parsing plus media download is slow and non-idempotent if interrupted.
• Model podcasts as Series. The natural mapping is one podcast feed → one Series, one episode → one MultimediaObject attached to that series. Keep that invariant; it means the rest of PuMuKIT (player, search, admin) works on podcast content with no special-casing.
• Store feed identity on the Series. Keep the feed URL and any episode GUID in the series properties/tags so re-imports are idempotent. Without this you get duplicate episodes on every cron run.
• Use PuMuKIT tags for episode state. Track "downloaded / published / failed" via the standard tag system so the admin UI reflects podcast status without custom schema.
• Export side: if you're generating a podcast RSS from a PuMuKIT series, generate it as a template rendered from SeriesBundle data, not from a separate query layer. The bundle's job is to expose the feed route and enclosure URLs; the data is already there.

Workflow integration tips:

• Configure via the bundle's extension config (config/packages/pumukit_podcast.yaml or app/config/config.yml depending on version). Expect keys for feed base URL, storage path for enclosures, and allowed MIME/media types.
• Hook into PuMuKIT's media-processing pipeline for transcoding to podcast-friendly audio. Don't try to bolt transcoding onto the bundle itself.
• Test against a real feed (a large public RSS feed) early. Podcast feeds have inconsistent namespaces and enclosures; a two-episode test feed will lie to you.

Gotchas and Tips

• Abandonment risk is real. 1 star, 0 dependents, low activity means no community support and no guaranteed fixes. Budget to read and patch the source yourself. Vendor the bundle (or fork it) rather than depending on upstream stability.
• Version coupling is the #1 failure mode. PuMuKIT's schema and service names change between releases. A mismatch produces confusing container/DI errors, not clear version errors. Pin both.
• Feed parsing edge cases: missing guid, relative enclosure URLs, itunes: extensions, redirects, and partial downloads. Wrap the import in try/catch per-episode so one bad item doesn't abort the whole run.
• Idempotency / deduplication: re-running import without GUID tracking is the most common source of duplicate media in PuMuKIT. Verify this before leaving it on a cron.
• Storage paths and permissions: the enclosure/media target directory must be writable by the web user and the CLI user (they often differ). Silent import failures are usually permissions.
• Long-running jobs: media download is I/O bound; use a dedicated worker with a longer max_execution_time and memory limit, or you'll see partial imports.
• Debugging: enable verbose console output (-vvv) and check the Symfony profiler for DI errors. Because there's no documentation, add your own logging at import boundaries — you will be the maintainer.
• Extension points: if you need custom behavior, prefer Symfony events/listeners or decorating the bundle's services over editing the bundle in place, so PuMuKIT core upgrades stay feasible.
• Fallback plan: if the bundle's scope drifts from your needs, implementing feed ingest as a small Symfony command against PuMuKIT's own services is often less work than fighting an unmaintained integration layer.