H5P Core Laravel Package

Technical Evaluation

Architecture fit h5p/h5p-core (h5p-php-library) is not a Laravel package — it is a framework-agnostic PHP core with no service provider, no config file, no migrations, and no Laravel-facing contracts. It is designed for host-application embedding via two seams:

• H5PFrameworkInterface — the host must implement ~40–50 methods covering library registry CRUD, content CRUD, file URL resolution, translation loading, and export/import bookkeeping. This is the real integration surface.
• A filesystem layout contract (content/, libraries/, temp/, editor/) that the core reads and writes directly.

Conceptually this fits Laravel well as a bounded-context module (its own service provider, its own DB connection or table prefix, its own storage disk), but it is not a drop-in dependency. The TPM framing should be "adopt a library and build an adapter," not "install a package."

Integration feasibility Moderate-to-high effort, well-bounded. The interface is explicit and stable-ish, which makes the work estimable. The realistic paths are:

1. Write a first-party adapter over Eloquent/Query Builder and a dedicated storage disk — most control, ~2–4 weeks to a player-only MVP.
2. Fork/adapt laravel-h5p as a reference implementation — faster start, but you inherit an opinionated, thinly maintained wrapper you will likely outgrow.

The player itself is client-side JS (h5p.js + per-library bundles); only content resolution, library management, and the editor are PHP-side. That means the PHP footprint can be kept narrow.

Technical risk

• GPL-3.0 (highest-severity item). Copyleft with strong obligations on distribution. SaaS-hosted internal use is generally defensible; shipping an on-prem appliance, white-label build, or distributed binary triggers source-disclosure obligations for the combined work. This is a legal gate, not an engineering preference — resolve before any build commitment.
• Stored XSS by design. H5P content packages contain author-supplied HTML/JS executed same-origin. Core provides some validation, but production hardening (strict CSP, sandboxed iframe on an isolated subdomain, Content-Type/X-Content-Type-Options, upload validation) is on the integrator.
• Archive handling. .h5p uploads are ZIPs; need zip-slip, zip-bomb, and size/quota controls around extraction.
• Filesystem coupling. Core assumes writable local directories and synchronous file access. Stateless/multi-node deployments and S3-backed storage require custom work in the framework adapter's file methods.
• Dependency graph fragility. H5P libraries carry their own semantic-ish versioned dependency trees. An unvetted library upgrade can silently break existing content rendering. A pinned library manifest is mandatory.
• Legacy front end. Editor is jQuery-era with older build tooling; no modern framework story.
• Adoption signal is weak. 152 stars and 0 Composer dependents means near-zero ecosystem pressure-testing of Laravel integration; you are an early adopter bearing the discovery cost. High "opportunity" score reflects an unmet niche, not proven demand.

Key questions

• Distribution model: hosted SaaS only, or anything shipped to customers? (Determines whether GPL is a blocker.)
• Who authors content — trusted internal staff or untrusted end users? (Determines XSS hardening scope.)
• Do we need the authoring editor, or player-only? (Roughly halves the effort and most of the risk.)
• Storage target: local disk, shared volume, or object storage?
• Laravel/PHP version support matrix and who owns the adapter long-term?
• Is there appetite to vendor/fork and maintain, or does this need to stay a clean dependency?

Integration Approach

Stack fit Laravel 10/11 on PHP 8.1+ is workable — the core is plain PHP with no conflicting framework assumptions. The natural shape is a self-contained module:

• One service provider binding an H5PFramework adapter implementation.
• A dedicated DB connection or table prefix (h5p_*) to isolate schema.
• A dedicated storage disk with a public URL mapping for content/ and libraries/.
• Player rendered inside an iframe pointing at an isolated route or subdomain, keeping H5P JS out of the main app origin.

Migration path

1. Spike (1 week): minimal adapter, local disk, one content type (e.g., Multiple Choice) rendering end-to-end. Validate the interface surface and library install flow.
2. Legal gate: GPL review against the distribution model before further spend.
3. Adapter decision: build first-party vs. fork laravel-h5p. Default to first-party unless timeline is aggressive.
4. Player-only MVP: content resolution, library registry, asset serving, iframe isolation, CSP. No editor.
5. Editor enablement: upload pipeline, library management UI, quotas, extraction hardening.
6. Content lifecycle: export/import, copy, versioning, library upgrade tooling.

Compatibility Pin the core to an explicit tag and vendor it in-repo (GPL permits and this simplifies patching). Maintain a library lockfile — a versioned manifest of installed H5P content-type libraries — and treat library upgrades as a release-gated operation with regression content. Do not let library versions float; do not run composer update against this dependency unsupervised.

Sequencing Adapter → asset/file serving → player → hardening → editor → lifecycle/upgrade tooling. Editor last: it is the largest surface, the highest security exposure, and the least valuable until players work. Keeping the player on a separate origin from day one avoids a painful retrofit later.

Operational Impact

Maintenance You own the adapter permanently; upstream does not know or care about Laravel. Upstream is a small team with an active but modest release cadence — expect periodic security patches (editor, archive handling) and PHP-version bumps. Budget roughly 0.2–0.5 FTE steady state, with spike quarters when a content-type library or the editor needs upgrading. Vendoring the source means you can patch, but also means you must track upstream.

Support Support burden lands mostly on content authors, not infrastructure. The H5P editor UX is idiosyncratic and undocumented for end users; expect training material, a content-type allowlist, and a "why did my presentation break" support path. Infra support is comparatively light once the iframe isolation and storage layout are stable.

Scaling PHP work is request-bound and modest (content metadata, library resolution). The heavy load is static assets — every content type ships many JS/CSS/font files. Put a CDN in front of libraries/ and content/; that is the difference between a cheap deployment and a slow one. Watch inode/file count: each installed content type expands into dozens-to-hundreds of files, which is unfriendly to object stores and to backup tooling. Editor uploads need size caps and, ideally, async processing.

Failure modes

• Library dependency mismatch after upgrade → blank/broken player with no useful error. Mitigate with a pinned manifest and a regression content set in CI.
• Writable-directory permission or disk-full errors → content creation fails opaquely.
• Partial ZIP extraction on upload → orphaned content rows.
• CSP misconfiguration → player silently blocked; easy to ship, hard to diagnose.
• Same-origin XSS via authored content — the failure mode with real blast radius.
• Multi-node deployments without shared storage → content created on one node 404s on another.

Ramp-up No official Laravel documentation exists; onboarding means reading H5PFrameworkInterface and a community wrapper. A competent Laravel engineer reaches a player-only MVP in ~2–4 weeks; a production editor with security hardening, quotas, and library management is realistically 6–10 weeks. Add legal review time for GPL up front and ongoing content-author training on the business side. Total cost of ownership is dominated by the adapter and upgrade discipline, not by the initial integration.