Textarea Field Type Laravel Package

Getting Started

This is not a standalone package. anomaly/textarea-field_type is a field type addon for the Streams Platform (the engine behind PyroCMS / Anomaly Labs CMS). It only makes sense inside a project that already has anomaly/streams-platform installed and bootstrapped. If you composer require it into a plain Laravel app, nothing will happen.

Minimal steps:

1. Install into a Streams project

   composer require anomaly/textarea-field_type
   

   The addon's service provider is auto-registered by the Streams addon loader; there is usually no manual provider registration needed.

2. Look at these files first (the package is intentionally thin — expect ~3–5 meaningful files):

   • src/TextareaFieldType.php — the field type class. It almost certainly only sets $inputView = 'anomaly.field_type.textarea::input' and inherits everything else from Anomaly\Streams\Platform\Addon\FieldType\FieldType.
   • resources/views/input.twig — the actual <textarea> markup and how it reads field_type.config.*.
   • resources/config/config.php — the available options (rows, placeholder, maxlength, etc.).
   • resources/lang/en/ — labels/instructions used in the admin field editor.

3. First use case — a "summary" field on an entry stream. Define it in a stream migration or add it through the admin Streams UI:

   protected $fields = [
       'summary' => [
           'type'   => 'anomaly.field_type.textarea',
           'config' => [
               'rows'        => 8,
               'placeholder' => 'Short summary...',
           ],
       ],
   ];
   

4. Render it in a Twig view:

   {{ entry.summary|nl2br }}
   

That's the whole loop: assign the type to a field, configure rows/placeholder, render the raw text and format it in Twig. If that works, you've exercised 100% of what this package does on its own.

Implementation Patterns

Assign via migrations, not the UI, for anything reproducible. Streams migrations are the normal way teams version field assignments. Use the field type slug exactly as registered:

'body' => [
    'type' => 'anomaly.field_type.textarea',
    'config' => [
        'rows' => 12,
    ],
],

Treat configuration as pass-through. The config array is handed straight to the Twig input view. So the practical set of options is whatever input.twig reads — typically rows, placeholder, maxlength, maybe height. Read the view before assuming an option exists; there is no schema validation stopping you from setting a key that does nothing.

Set and read values through the normal Streams entry API. This is not a bespoke storage layer — it writes to the stream's text column like any other field type:

$entry->summary = $request->get('summary');
$entry->save();

// or via repository
$entries->find($id)->getSummary();

Format at render time, not storage time. Store raw text; apply |nl2br, |markdown, or a purifier filter in Twig. This keeps the field type reusable and avoids baking presentation into the database.

Reuse it as a building block. Because it's just a FieldType subclass with an $inputView, the common extension pattern is to write your own field type that extends TextareaFieldType (or the base FieldType), points at your own view, and adds behavior (e.g., a markdown textarea, a JSON textarea with validation). You rarely mutate this package — you subclass it in your own addon.

Override the view rather than fork the package. Publish/override resources/views/input.twig through the platform's view override mechanism (or your own addon's view path if the loader supports namespaced overrides) so composer updates don't clobber your markup.

Pair it with validation in the stream/form layer. The field type handles input rendering only; required/max-length enforcement belongs in your form request or stream field rules. Do not assume maxlength in config is enforced server-side — verify in input.twig whether it's a client-side maxlength attribute only.

Use it for the "long text" half of a content model. Typical day-to-day placements: summary, notes, meta_description, admin_notes, address. For anything that needs rich formatting, use the wysiwyg field type instead — this one is plain text.

Gotchas and Tips

• It cannot run standalone. Every "it doesn't work" report for this package is usually a missing anomaly/streams-platform install or a broken addon cache. Run the platform's addon refresh/clear-cache command after install before debugging anything else.

• The package is essentially a view + a class alias. Do not expect helpers, validation, purifying, or sanitization. If you need HTML-safe output you must escape/purify in your own template.

• Zero stars / zero dependents is a real signal. This is a first-party-style addon from a small ecosystem, not a battle-tested community package. Pin the version in composer.json, and read composer.json's require constraints to confirm it matches your anomaly/streams-platform major version. Mismatched platform majors are the most likely breakage.

• The input view path is namespaced (anomaly.field_type.textarea::input). If you override it, keep the namespace intact or the field will render blank with no obvious error. Suspect this first when a textarea renders as nothing.

• null vs empty string. Long-text fields frequently come back null when never saved. Guard with {% if entry.summary %} rather than {% if entry.summary is not empty %} if you're unsure how the platform normalizes it — test the unsaved/cleared case explicitly.

• Rows is cosmetic; overflow is content. A rows => 4 config still stores unlimited text unless you add a length rule. Don't confuse the visual height with a limit.

• Multilingual streams. If your stream is translatable, the textarea value is stored per-locale. Test switching locales in the admin — a common bug is assuming one value across locales.

• Debugging tips:

  • Confirm the field type is registered: check the admin field-type dropdown, or inspect the addon list.
  • If config isn't taking effect, dump field_type.config inside a temporary copy of input.twig — that's the ground truth for what the view actually receives.
  • If the whole form breaks, revert to the stock view first to rule out your override.

• Extension point to remember: $inputView on the field type class is the single most useful hook. Changing that one property (in a subclass) is how you customize rendering without touching this package.

• Maintenance reality check: with no dependents and low activity, budget for reading the source yourself rather than finding answers online. The good news is the source is small enough to read end-to-end in ten minutes — do that before your first integration rather than after your first bug.