Decimal Field Type Laravel Package

Getting Started

anomaly/decimal-field_type is an addon for the Streams Platform (PyroCMS 3 / Laravel-based). It registers a single field type, anomaly.field_type.decimal, that renders an <input type="number"> with configurable min, max, step, and display decimals. It is deliberately thin — there is no business logic beyond configurable attributes and a raw value pass-through.

Requirements. A working Streams Platform install (anomaly/streams-platform, typically inside PyroCMS 3.x). This is not a standalone Laravel package; it does nothing without the platform.

Install.

composer require anomaly/decimal-field_type
php artisan addon:install anomaly.decimal_field_type   # if not auto-installed
php artisan streams:compile

Where to look first.

1. src/DecimalFieldType.php — the config getters (getStep(), getMin(), getMax(), getDecimals()) are the entire public surface.
2. resources/views/input.twig — the form markup; this is where the HTML5 attributes are wired.
3. The README — short, but lists the supported config keys.
4. composer.json — check the require block against your Laravel/PHP version before committing (see Gotchas).

First use case. Add a "Unit Price" field to a products stream: choose the Decimal field type, then set min: 0, max: 999999, step: 0.01, decimals: 2. The admin entry form now renders a numeric input with the correct step, and the stored value comes back as a plain numeric scalar when you read $product->price or {{ product.price }}.

Implementation Patterns

Declaring the field in a migration/seeder (preferred over clicking through the admin UI, because the config is version-controlled):

$stream->addField('price', 'anomaly.field_type.decimal', [
    'config' => [
        'min'      => 0,
        'max'      => 999999,
        'step'     => 0.01,
        'decimals' => 2,
    ],
    'rules' => ['required', 'numeric', 'min:0'],
]);

Reusing one definition across streams. Define the field config once in a helper/constant and pass it to every addField() call so prices, tax rates, and weights all behave consistently:

const MONEY_CONFIG = ['min' => 0, 'max' => 999999, 'step' => 0.01, 'decimals' => 2];

$stream->addField('subtotal', 'anomaly.field_type.decimal', ['config' => self::MONEY_CONFIG]);
$stream->addField('tax',      'anomaly.field_type.decimal', ['config' => self::MONEY_CONFIG]);

Server-side validation is your responsibility. The HTML5 min/max/step attributes do not enforce anything on the server. Always pair the field with rules:

'rules' => ['nullable', 'numeric', 'between:0,999999']

Reading values. In PHP, $entry->price returns the raw scalar. In Twig, {{ entry.price }} prints it. If you need formatted output (thousands separators, fixed decimals), either use Twig's filter directly or override the presenter:

{{ entry.price|number_format(2, '.', ',') }}

Presenter override for a consistent format() method across templates:

namespace App\Presenters;

class PricePresenter extends \Anomaly\DecimalFieldType\DecimalFieldTypePresenter
{
    public function format()
    {
        return number_format((float) $this->value, 2, '.', ',');
    }
}

Then reference it from the field or entry presenters.

Integration tip — currency display. This field stores a bare number. Pair it with anomaly/currency-field_type (or a plain string field) to capture the currency code, then compose them in the view: {{ entry.currency }} {{ entry.price|number_format(2) }}. Don't try to encode currency into the decimal field itself.

Workflow for schema changes. Field config lives in streams_fields.config (JSON). Editing it in the admin panel is fine for prototyping; for anything shipped, edit the migration and re-run. After changing config, run php artisan streams:compile so the platform recompiles field metadata and cached views.

Gotchas and Tips

Database column precision. The Streams migration builder maps this field to a numeric column, but you should verify the generated column type. If you need exact money handling, explicitly define the column as decimal(10,2) rather than relying on a float/double mapping — floating-point drift is a real hazard for stored currency values. Keep the storage column and the field's decimals config in agreement.

step and decimals must match. If step is 0.01 but your validation or storage assumes 4 places, the browser will silently reject values like 1.2345 (a step mismatch) while a direct API POST bypasses the check entirely. Keep step, decimals, and the DB scale in lockstep, and validate server-side.

Locale decimal separators. HTML5 number inputs use . as the decimal separator regardless of the user's locale. Users on comma-decimal locales may type 1,50 and get an empty/invalid field. If locale input matters, you'll need a custom input view; this package does not handle locale parsing.

Package age and compatibility. Last release is June 2020, with zero dependents and no ecosystem activity. Before adopting, confirm it installs against your platform's Laravel version (service-provider auto-discovery style changed across Laravel 5→8) and that it runs on your PHP version. Treat it as a very small wrapper you can vendor/fork if the dependency becomes stale — the entire logic is a handful of config getters plus a Twig input, so a fork is cheap.

Debugging field behavior. When the input looks wrong:

• Inspect the stream field's config JSON in the streams_fields table to confirm your attributes actually persisted.
• Run php artisan cache:clear && php artisan streams:compile after config edits.
• Check the compiled/published input.twig if you've overridden views — a stale published view is a common cause of "my change didn't take."

Extension points. Override getStep(), getMin(), getMax(), or getDecimals() in a subclass to derive config dynamically (e.g., decimals driven by a setting). Override the presenter for formatting. Replace the input view via the standard Streams view override convention if you need custom markup (units, sliders, masked input).

Don't expect automatic formatting. The field type returns the stored number as-is; there is no built-in currency or thousands-separator formatting. Every "why does it show 10 instead of 10.00" report traces back to this — format in Twig or the presenter, not in the field.