Laravel Mutable Content Daisyui Laravel Package

Getting Started

1. Upgrade core first. v0.4.1 requires core ^0.7.7. Bump the core constraint before or alongside this package, otherwise Composer will resolve an incompatible pair and field definitions may fail to hydrate (the decimals type setting is read from core).
2. Install / update the package via Composer, then run any pending migrations and publish config if you have not already:

   composer require <vendor>/<package>:^0.4.1
   php artisan vendor:publish --tag=<package>-config   # if applicable
   php artisan migrate
   

3. Look first at the field type registry/config — this is where number and money types (and their allowed settings such as decimals, allow_negative, allow_zero) are declared. That file tells you what the fields screen and usage forms can actually render.
4. First use case: add a money field to an entity. On the fields screen, create the field, pick the money type, and set “Digits after the point” (the decimals setting). Add the field to a usage form, then confirm the generated money column and cast honour the decimals value. This end-to-end path (field screen → usage form → column) is the fastest way to validate your install.

Implementation Patterns

• Configure decimals at the field level, not the column. decimals is a type setting stored on the field definition. Set it once on the fields screen and every form/column derived from that field should read it. Avoid hard-coding precision in Blade/column renderers.
• Rely on type defaults for numeric switches. Since v0.4.1, a newly created number/money field inherits allow_negative and allow_zero defaults from the chosen type rather than being forced off. Define sensible defaults in your field type config so forms, API validation, and imports all agree.
• Pair the field with matching validation. Generate rules from the same settings you render: numeric, decimal:0,N (where N = decimals), min:0 unless negative is allowed, and not_in:0 (or gt:0) when zero is disallowed. Keep this in a single rule factory so the form and programmatic saves stay consistent.
• Treat money as fixed-point end-to-end. Store money columns as integer minor units or DECIMAL(…, N) matching decimals, and cast/normalise on the model. Format only at the presentation edge.
• Round-trip through the usage form. When a field is attached to a usage form, verify the submitted value survives: field config → form input → model cast → column formatting. Divergence here (e.g. form allows 2 decimals, column formats 0) is the most common integration bug.
• Test field creation programmatically. Use factories/builders to create a field of each type and assert the resolved defaults (allow_negative, allow_zero, decimals) so future core bumps don’t silently change behaviour.

Gotchas and Tips

• Core version drift is the main footgun. v0.4.1 depends on core ^0.7.7; running an older core can yield missing decimals handling or stale field metadata. Pin both packages together in composer.json and check composer why-not when resolution fails.
• The defaults fix only applies to newly created fields. Existing number/money fields created before v0.4.1 keep whatever allow_negative/allow_zero values they were saved with — including the previously forced-off switches. Audit and backfill existing field definitions if you expected negatives or zero to be permitted.
• decimals is a type setting, not per-usage. Changing it later affects the stored config and therefore all usages/columns for that field. Widening precision after data exists is a migration concern (column type and rounding of existing values), not just a UI toggle.
• Watch display vs. storage rounding. A decimals-aware column may render rounded values while the database holds more precision (or vice versa). Decide where rounding happens and be consistent; for money, round at input/validation time and store the rounded value.
• Currency is not implied. The release only covers decimal precision, not currency codes or conversion — keep currency handling in your own model/attribute layer.
• Debugging tip: when a form renders the wrong switches or precision, dump the resolved field type config (not just the request payload) — the defaults are resolved from the type at creation time, so a mismatch usually points at the type definition or a stale field record.
• Extension point: centralise number/money behaviour in your field type class (defaults + validation + column formatting). That is the seam to override if you need custom precision rules, negative handling for specific entities, or different storage strategies — rather than patching form or column components individually.