Pumukit Lms Bundle Laravel Package

Technical Evaluation

Architecture fit — the headline finding: Despite being scoped as a Laravel/PHP package, teltek/pumukit-lms-bundle is a Symfony bundle, not a Laravel package. PuMuKIT is a Symfony-based video/lecture-capture platform (maintained by Teltek, UPV), and this bundle is the LMS-integration layer that bolts LTI-based video embedding into a PuMuKIT instance. It assumes Symfony's kernel/bundle registration, the Symfony DI container, Doctrine ORM entities and migrations, Symfony routing and security firewalls, Twig templating, and PuMuKIT's own sibling bundles (pumukit/core-bundle, schema-bundle, paella-bundle, etc.). None of that maps onto Laravel's service providers, Eloquent, Blade, or HTTP kernel. There is no adapter layer, no framework-agnostic core, and no Laravel service provider shipped. Installing it into a Laravel app via Composer will autoload classes but will not produce a working integration — the bundle has no entry point Laravel can drive.

Integration feasibility: Feasible only in one of two shapes. (1) Only if the host application is PuMuKIT — then this bundle is a natural, first-class fit and the integration cost is configuration, not code. (2) If the host is Laravel — then this package must not be vendored. Instead, treat PuMuKIT as a separate LTI tool service and integrate Laravel with it over the LTI protocol (or PuMuKIT's REST/API surface), keeping the two runtimes in separate containers. That is a legitimate architecture, but note that in that shape the bundle itself is an implementation detail inside the sidecar and your team never depends on its code directly.

Technical risk:

• Adoption risk (high). 2 stars, 0 dependents. Effectively zero third-party validation; no ecosystem of fork fixes, blog posts, or Stack Overflow answers. The opportunity score of 24 and composite 0.04 reflect this accurately — this is a niche component of a niche platform.
• Maintenance risk (high). Single-vendor stewardship. Version cadence tracks PuMuKIT releases, which are infrequent relative to the wider PHP ecosystem. Symfony major-version upgrades (3.4 → 4 → 5 → 6) historically require bundle rewrites; the bundle's compatibility ceiling with modern PHP/Symfony is the first thing to verify and the most likely blocker.
• Protocol risk (medium-high). LMS integration here is LTI-centric, and older PuMuKIT generations lean on LTI 1.1 (OAuth 1.0a, shared consumer key/secret). LTI 1.1 is deprecated in favor of LTI 1.3 / LTI Advantage (OAuth 2.0 + JWT + JWKS). Moodle, Canvas, and Blackboard still accept 1.1 for now, but the direction of travel is clear; verify whether the bundle in question supports 1.3 and Deep Linking 2.0.
• Security surface (medium). An LTI launch endpoint is an unauthenticated, internet-facing authentication entry point. Shared-secret models are brittle (secret rotation, replay windows, clock skew) and a misconfiguration can leak a course-level SSO bypass.
• Licensing/ops risk (low-medium). Presumed open source, but Teltek's commercial support model means the "supported" path is a contract, not a community.

Key questions to resolve before committing:

1. What Symfony and PHP version constraints does the current composer.json declare, and is the bundle actively released (commit recency, tagged releases, open-issue backlog)?
2. Does it implement LTI 1.3 / LTI Advantage, or only 1.1? Is Deep Linking supported (needed for content-item selection inside a course)?
3. Is PuMuKIT a mandated platform in our organization already, or would adopting this bundle force adopting PuMuKIT wholesale?
4. What is the actual user story — SSO from LMS into video, embedding videos in courses, or gradebook passback? Gradebook/assignment-and-grades (AGS) is a materially harder requirement than embedding.
5. Is there a commercial support contract available, and what is the cost relative to building a thin LTI 1.3 integration ourselves?

Integration Approach

Stack fit. Misaligned by default for a Laravel shop. The bundle's dependency graph pulls Symfony components, Doctrine, and PuMuKIT siblings — a parallel framework runtime inside a Laravel monolith is not a tenable steady state. The correct fit is service-oriented: Laravel remains the product/portal; PuMuKIT (with this bundle) runs as an independent LTI tool service behind its own domain and database.

Migration path. Do not attempt a code-level port. Instead:

1. Stand up PuMuKIT in a container (Docker image or Ansible-provisioned VM per Teltek's docs) with the LMS bundle enabled, pinned to a specific PuMuKIT release tag.
2. Register it as an external tool in the target LMS (Moodle/Canvas) with its own key/secret (or 1.3 client registration), independent of your Laravel app.
3. Bridge identity at the edges — if you need single sign-on continuity between Laravel and PuMuKIT, do it via a shared IdP (SAML/OIDC) rather than by sharing sessions or databases.
4. Only if genuinely required, call PuMuKIT's API from Laravel for catalog/embed metadata; keep that contract thin and versioned.

If the org's actual goal is "Laravel app needs to talk to an LMS," the more defensible path is to skip this package entirely and integrate Laravel directly into the LMS via an LTI 1.3 library or the LMS's native REST API (Moodle web services, Canvas API). That gives you a single-stack solution and avoids the entire Symfony/PuMuKIT dependency tree.

Compatibility. Verify three things in a spike: (a) the bundle's Symfony/PHP ceiling versus your container base image, (b) Doctrine schema migrations against a clean database, (c) LTI version negotiated by your LMS. Any of these failing is a stop-ship signal, not a workaround candidate.

Sequencing.

1. Two-day spike — clone PuMuKIT + bundle, boot locally, complete one LTI launch from a test Moodle. If this does not work cleanly, stop.
2. Contract validation — confirm LTI version, Deep Linking, and gradebook requirements against the spike.
3. Isolated deployment — PuMuKIT service in its own namespace/environment, not co-located with Laravel.
4. Pilot with one course — observe launch latency, enrollment mapping accuracy, and video embedding behavior.
5. Broaden rollout — after a full term or a defined soak period, decide whether to adopt permanently, buy support, or replace with a native LTI 1.3 integration.

Operational Impact

Maintenance. You are adopting a codebase you likely cannot rely on upstream to keep current. Budget for a fork-and-own posture: pin the version, vendor the source into your artifact registry, and assume you will apply Symfony/PHP compatibility patches yourself if the platform version advances. Track upstream commits, but do not depend on them for security fixes.

Support. Community support is effectively nil (2 stars, 0 dependents). Teltek offers commercial support for PuMuKIT — treat that as a required line item if the integration becomes business-critical, and price it against the alternative of a native LTI integration. Internal knowledge concentration is a real risk: plan for at least two engineers with hands-on exposure, not one.

Scaling. Two distinct scaling profiles. LTI launch traffic is bursty — synchronized class starts produce launch spikes, so the tool endpoint must handle concurrency without queueing behind video work. Video processing (transcoding, storage, streaming) is the genuinely expensive dimension and dominates infra cost; it scales with content volume, not with LMS user count. Isolate the launch/auth path from the transcoding pipeline so one does not starve the other.

Failure modes to instrument and alert on:

• LTI launch failure (secret mismatch, expired key, OAuth clock skew, JWT/JWKS fetch failure) — users see a broken embed inside the LMS; error surfaces in the LMS iframe, not in your dashboards. This is the highest-frequency, highest-visibility failure and needs explicit synthetic monitoring.
• Course/enrollment mapping drift — renamed or archived courses leaving orphaned mappings and stale permissions; typically discovered as a permissions complaint, not an infrastructure alert.
• Version skew between PuMuKIT and the LMS's LTI implementation — silent, and only appears when the LMS changes behavior.
• Database migration failure during upgrades — Doctrine migrations in a stateful service; requires tested rollback.
• Certificate/secret expiry — annual, predictable, and universally forgotten.

Ramp-up. Non-trivial. Engineers need working knowledge of: Symfony bundle/DI conventions, the LTI specification (1.1 vs 1.3, launch flow, Deep Linking), PuMuKIT's domain model (series, multimedia objects, tracks, tags), and the target LMS's external-tool configuration. Realistically 2–4 weeks to first competent change, longer if the team has no Symfony experience. If the team is Laravel-native, that Symfony ramp-up cost is a recurring tax on every future change and should be weighed explicitly against a native integration built in a stack the team already knows.

PM verdict. The integration is technically possible but organizationally expensive, and the package's near-zero adoption means you are effectively the maintainer. Recommend proceeding only if PuMuKIT is already an established organizational platform with support in place; otherwise, scope the underlying requirement (LTI-based video embedding) and satisfy it with a direct LMS integration in the team's own stack, treating this bundle as an architectural anti-pattern for a Laravel codebase.