Boolean Inline Laravel Package

Getting Started

Version 1.0.2 is a patch release — the only change is "Solve the Update with other fields", i.e. a bug fix for updating a record while passing additional/non-model fields alongside the attributes being persisted. There is no new API surface to learn, so if you are already on 1.0.x this is a drop-in composer update.

Minimal steps:

1. composer require <vendor>/<package> (or composer update <vendor>/<package> if already installed) and confirm you land on 1.0.2 with composer show <vendor>/<package>.
2. Open the package's README.md first, then src/ — for a package this small the README is usually the entire documentation, and the service provider / facade is the fastest way to see what is actually bound into the container.
3. Check config/<package>.php (publish with php artisan vendor:publish --tag=<package>-config if present) for anything that affects update behaviour — table names, fillable guards, or a "strict fields" style toggle.
4. First use case worth exercising: take an existing Eloquent model, perform an update that mixes real column values with extra keys (e.g. a redirect_to, notify, or form-only flag) and confirm the extra keys are ignored rather than causing a SQLSTATE unknown-column error or a MassAssignmentException.

Because the fix targets update-with-extra-fields specifically, your regression test should be exactly that scenario — this is the code path that was broken pre-1.0.2.

Implementation Patterns

Update with mixed payloads. The canonical pattern this release enables: separate your request data into model attributes and meta/control fields, but still hand the whole array to the package and let it decide what to persist. Prefer this over manually Arr::only()-ing at every call site, but assert the behaviour in a test so you notice if it regresses.

Wrap in a transaction when the update fans out. If your extra fields trigger side effects (sending notifications, writing an audit row), wrap the update plus side effects in DB::transaction() so a failed update doesn't leave a half-applied notification.

Form Requests as the boundary. Keep validation in a FormRequest and pass $request->validated(); extra fields that survive validation are the ones this fix is about. Don't rely on the package to filter unvalidated input — treat it as a persistence helper, not a validator.

Integration with update flows. In a typical resource controller:

• store() — create path, unaffected by this release.
• update() — the path fixed in 1.0.2; cover it with a feature test that posts extra keys.
• Bulk/partial updates — verify separately; the fix likely applies per-record, not to query-builder style mass updates.

Testing tip. Write one test that asserts only the expected columns changed (assertDatabaseHas for the real fields, and confirm the extra key does not exist as a column / is absent from getAttributes()), plus one that asserts the extra values are still accessible to your controller logic if the package returns them.

Pin the version. Given the package is at 1.0.2, pin with a caret constraint (^1.0.2) so you don't silently pick up a 1.1.0 that may alter the field-filtering contract.

Gotchas and Tips

This is a behavioural fix, not a no-op. If you previously worked around the bug (e.g. by manually stripping fields before calling update), remove those workarounds and re-test — the double-filtering can hide the very regression you want to catch.

Watch for silent data loss. The most likely failure mode of a "ignore other fields" fix is over-filtering: a legitimately fillable column getting dropped because it wasn't in the model's $fillable or was excluded by a guard. After upgrading, diff the actual DB row against what you submitted on a real form, not just in unit tests.

Debugging. If an update still errors, log the exact array passed in (Log::debug() before the call) and compare against $model->getFillable(). Check whether the package uses fill() (respects $fillable/$guarded) or forceFill() (does not) — that determines whether your extra fields are merely ignored or actually cause an exception.

Config quirks. If the package ships a config with a field allowlist or a "sync/update strategy" option, changing it will change the semantics of this fix. Confirm the config is published and cached behaviour is refreshed (php artisan config:clear) after upgrade — stale cached config is a classic source of "the fix didn't work".

Extension points. If the update logic is resolvable from the container (a bound interface or a protected function in a base class), subclass or rebind rather than editing vendor code; the package is young enough that internals will likely change again.

Release hygiene. The changelog entry is terse ("Solve the Update with other fields"). Before a wider rollout, check the diff between 1.0.1 and 1.0.2 in src/ — a one-line changelog can conceal a multi-file change. If the diff touches anything beyond the update path, treat it as slightly higher risk and stage the upgrade.

No documented breaking changes. Nothing in 1.0.2 signals deprecations or API removal, so upgrading from 1.0.1 is safe to do opportunistically — but keep the pre-upgrade workaround commit handy until your feature tests pass.