Input File Field Type Laravel Package

Getting Started

This is a Streams Platform field type addon, not a standalone package. You need a working PyroCMS 3.x (or bare Streams Platform) install before it does anything.

Install:

composer require visiosoft/input_file-field_type
php artisan addon:install visiosoft.field_type.input_file

Where to look first:

1. config/ in the package for the field type's default configuration options.
2. The generated FieldType class (typically InputFileFieldType.php in src/) — this is where input/output rendering, getRules(), and DB column handling live.
3. The resources/views/ folder for the input/output Blade views — this tells you exactly what the field expects and returns.
4. migrations/ if present, to see whether the field type ships its own setup (most Streams field types don't, but verify).

First use case: Attach a file (via upload or a stored path) to any stream entry. Register the field on a stream:

$stream->addField('document', 'input_file', [
    'required' => true,
    // whatever config keys the field type's view/config exposes
]);

Then render it in a form:

{{ form('example')->fields(['document'])->get() }}

Open the admin entry form first — if the field renders but doesn't save, the problem is almost always the field type's mutator/accessor, not your form.

Implementation Patterns

Use it as one field on an existing stream, not as the primary storage mechanism. This field type is designed to slot into a Streams form; treat it as a "pick a file" control for a record. Pair it with a stream that already models your domain entity (Order, Asset, Template, etc.) rather than building a new stream just to hold files.

Accessor pattern for downstream code: Because field types return a FieldType wrapper, always read through the entry's field accessor so you get the file object back rather than a raw column value:

$file = $entry->document;          // File/Document object
$url  = $entry->document->url();  // if the field type wraps a file

If your template needs a raw path, add a small helper on the entry's presenter — do not reach into $entry->document->getValue()->path() inside Blade, it will break as the field type evolves.

Saving programmatically: For imports/seeders, set the field using the same shape the field type's getInputView() consumes. In practice that means assigning a file ID or an upload path the field type's getValue() can resolve. Check the field type's getValue()/putValue() before writing bulk imports; otherwise you'll store strings where the field expects an object.

Validation: Field type validation lives on the field type itself (getRules()), not your FormRequest. If you need extra constraints, extend via $stream->addField(...) config where the field type reads it, or wrap with a custom form handler — do not duplicate rules in the request, they'll drift.

Migration pattern:

public function up()
{
    if (! $this->fields->exists('orders', 'invoice')) {
        $this->fields->add('orders', 'invoice', 'input_file', [
            'required' => false,
        ]);
    }
}

Guard with exists() — Streams migrations are not idempotent and re-running add on an existing field throws.

Pairing with other addons: This field type is usually combined with visiosoft/files-module / files-field_type for the actual storage layer. If you find the stored value is empty after upload, the input file field type is likely delegating to that storage module — confirm it's installed and its config points to the right disk.

Gotchas and Tips

Abandoned since Feb 2022. The Streams Platform field type API has moved since then (return types on getValue()/putValue(), Blade component conventions). Before adopting, run composer require visiosoft/input_file-field_type against your PyroCMS version and check for signature-compatibility deprecations. Pin the exact version in composer.json — there will not be fixes.

Zero stars, zero dependents = no community knowledge base. Any problem you hit is yours. Budget time to read the field type source end-to-end (it's small) before you debug at runtime. This also means: don't use it as the core of a feature you can't afford to rewrite.

Name ambiguity. "input_file" reads like it might be a widget for ingesting a file into a processing pipeline rather than a general upload field. Read the getInputView() Blade first to confirm what it actually renders — an <input type="file">, a picker, or a path text field — before designing the surrounding UI. If it's a raw <input type="file">, you'll get no validation, no thumbnails, and no drag-drop; expect to wrap it.

Disk config. File fields store references, and the disk is configured at the fields module or Streams storage level, not per-field by default. If uploads go to the wrong place (or to local when you want S3), you're editing the storage addon's config, not this package's.

Field type registration cache. After addon:install, run php artisan addon:reload (or streams:reload) — otherwise the new field type won't appear in the add-field dropdown and you'll waste time thinking the install failed.

Debugging empty values: Add a temporary dd($fieldType->getValue()) inside the field type's getValue() to confirm what's stored vs. what's expected. Nine times out of ten the DB column holds the ID/path but the accessor is failing to hydrate it (missing storage addon, deleted file, wrong disk) — the field type silently returns null.

Extension point: The cleanest customization is to extend the field type, not edit vendor code:

class CustomInputFileFieldType extends InputFileFieldType
{
    public function getRules() { return array_merge(parent::getRules(), ['mimes:pdf,docx']); }
}

Register it under your own namespace to get additional validation, custom views, or a different storage adapter while still inheriting the base behavior.

Migration rollback is not safe. Streams field types typically ship no down() for field removal from user streams, and removeField will drop data. Back up before rolling migrations back in any environment with real content.

If you're not on PyroCMS. This field type assumes the Streams Platform's form builder and addon loader. Pulling it into a plain Laravel app means porting the field type into a plain Blade partial plus your own upload handler — at which point you should just write the upload field yourself; the package gives you almost nothing.