Json Field Type Laravel Package

Technical Evaluation

Architecture fit. This is not a general-purpose Laravel package. It is a Streams Platform addon — a FieldType extension for PyroCMS and its OpenClassify fork. It depends on the Streams field-type contract, the addon manifest conventions, and the control-panel asset/view pipeline. Outside that runtime (vanilla Laravel, Nova, Filament, Livewire forms) it contributes nothing and cannot be wired in without reimplementation.

Integration feasibility. High if we are already running OpenClassify/PyroCMS with Streams — installation is a composer require plus addon registration plus assigning the field type to a stream field. Near-zero otherwise. The code surface is small, which keeps both the adoption cost and the replacement cost low.

Technical risk.

• Unmaintained since August 2019; predates several Laravel and PHP major-version transitions. Compatibility with any current Streams release is unverified and unlikely without patching.
• Zero stars and zero dependents means no production validation, no issue history to mine for known breakage, and no community fork to fall back on.
• License and provenance are unclear; verify before commercial use, as fork lineage between visiosoft and openclassify can create ambiguity.
• Schema-less JSON in a relational CMS invites data-quality debt: no enforced shape, no useful indexes, queries degrade to JSON-path or LIKE scans.
• Security surface: raw JSON edited in the admin panel must be validated server-side and escaped on render, or the field type becomes a stored-XSS and data-corruption vector.
• Supply chain: an abandoned transitive dependency inside an admin panel is a standing upgrade blocker.

Key questions.

1. What license, and who holds it?
2. Which Streams/PyroCMS, Laravel, and PHP versions are actually supported?
3. Is storage a text column or a native json column, and is there a cast?
4. Is input validated as JSON before persistence, and how are invalid values surfaced to the editor?
5. Does it ship a JS editor asset, and is that asset maintained and CSP-compatible?
6. Is the field free-form, or does it enforce a per-field schema?
7. Is upstream truly dead, or is the OpenClassify fork the live branch?

Integration Approach

Stack fit. Valid only on OpenClassify/PyroCMS with Streams. If our target application is any other Laravel stack, the correct answer is to stop here and write a native field type for whatever form layer we actually use.

Migration path. Do not consume this from Packagist as-is. Vendor it — fork into a private repository or copy the source into the addon directory — pin by commit, and treat it as first-party code. This grants patch rights and removes dependence on an abandoned upstream. Where practical, prefer a clean reimplementation: a PyroCMS JSON field type is typically a small class extending FieldType with input/output views plus a validation rule, which is likely cheaper to write fresh than to revive.

Compatibility. Verify against our pinned PHP, Laravel, and Streams versions with an explicit smoke test. Expect to patch the service provider registration, namespaces, and any helper or signature changes removed in later framework versions. Add a server-side JSON validation rule and output escaping regardless of what ships in the box.

Sequencing.

1. Spike in a feature branch: install, register, attach a JSON field to a scratch stream, exercise create/edit/render/index.
2. Write characterization tests around save, validate, and render before modifying anything.
3. Make the build-vs-adopt call explicitly, with the fork cost and the rewrite cost both estimated.
4. If adopted, harden: validation, escaping, documented shape per field.
5. Promote to staging, then to production behind a flag on one low-risk stream before wider use.

Operational Impact

Maintenance. We own it from day one. No upstream will absorb Laravel or PHP version bumps, so budget a recurring maintenance line — or eliminate the fork overhead entirely by replacing it with an in-house field type.

Support. None. No documentation, no issue triage, no security advisories. Internal ownership must be named explicitly, with a documented fallback if that individual leaves.

Scaling. The field type itself is thin and will not be a throughput bottleneck. The scaling risk is the data model: free-form JSON columns resist indexing, complicate reporting, and grow unbounded. Acceptable for config-like payloads; if JSON becomes the de facto schema for business entities, plan an extraction path before volume makes it expensive.

Failure modes.

• Silent data corruption: malformed or double-encoded JSON persisted, then a read path throws and blanks an admin page.
• Upgrade breakage: a PHP or Streams bump silently breaks the addon manifest or view namespace.
• Render-path XSS if output is not escaped.
• Abandonment drift: nobody notices it is broken until an editor cannot save content.

Ramp-up. Low for a Laravel developer familiar with Streams addons — hours, not days, to read the contract and the code. The real ramp-up cost is institutional: whoever adopts it also owns it, and no one else on the team will carry context.

Recommendation. Treat this repository as a reference implementation, not a dependency. Fork or reimplement under our own ownership if the JSON field type is genuinely needed.