Coretik Laravel Package

Getting Started

Coretik (idetik/coretik) is currently in the v2.0.0 beta line — the latest tag is 2.0.0-beta.11. Treat this as pre-release software: pin the exact version and read the diff between betas before bumping.

composer require idetik/coretik:2.0.0-beta.11

Because the package has no stable 2.x release yet, you will likely need an explicit stability flag in composer.json ("minimum-stability": "beta" with "prefer-stable": true) or an exact-version constraint so composer update doesn't drag you onto an untested beta.

Where to look first, in order:

1. CHANGELOG.md — the beta series is where the API is still moving. Read the whole 2.0.0 beta history, not just the latest entry, since there is no upgrade guide for unreleased majors.
2. src/Models/ and any src/Concerns/ directory — the v2.0.0-beta.11 feature ("models: add quiet meta updates", commit 85628af) lives here.
3. The package's test suite — for a beta, tests are the most reliable documentation of intended behaviour, especially for the quiet-write semantics.
4. Config file (publish it if the package ships one) — look for anything controlling hook/event dispatch, since that is what "quiet" almost certainly toggles.

First use case: a data import or migration where you are writing many meta values onto models and do not want each write to fire model events, observers, or underlying CMS hooks. That is the canonical reason a "quiet save" API exists, and it is exactly what beta.11 adds:

// Pseudocode — confirm exact method name against src/Models and the test suite.
foreach ($rows as $row) {
    $model->meta('seo_title', $row['title']);
    $model->saveQuietly(); // or ->quiet()->save(), depending on the v2 API
}

Start with one small importer, confirm no observers fire, then widen usage.

Implementation Patterns

Quiet writes for bulk/batch work. The core pattern the new feature enables is separating "does the write" from "announces the write". Use quiet meta updates in seeders, imports, backfills, sync jobs, and fixture loading. Anything that runs in a loop over more than a handful of records should probably be quiet.

Loud writes for user-facing edits. Keep the default (non-quiet) path for anything a human triggers in the UI. Those are the writes where cache invalidation, search indexing, webhooks, and audit logging are supposed to happen. The mental model is the same as Eloquent's save() vs saveQuietly(): quiet is an escape hatch, not a default.

Suppress, then announce once. A clean workflow is to perform the whole batch quietly and then dispatch a single explicit event/job at the end of the operation to refresh caches or trigger downstream consumers:

DB::transaction(function () use ($rows) {
    foreach ($rows as $row) {
        $this->upsertQuietly($row);
    }
});

SyncCompleted::dispatch($model); // one loud signal, not N

This gives you the performance and predictability of quiet writes without permanently starving listeners.

Wrap quiet regions narrowly. Prefer a per-call flag over a global "mute everything" toggle. If you find yourself muting for an entire request, that's usually a signal the observer logic is too heavy and should be moved into a queued job instead.

Integration with existing observers/listeners. Audit what currently listens to model meta changes before introducing quiet writes — anything that assumed "a meta write always fires" will silently break. Grep your app's observers, listeners, and any CMS-side hooks for the relevant events first.

Version discipline during beta. Pin exact betas (2.0.0-beta.11, not ^2.0.0@beta), and treat each bump as a mini-review. The major-version jump from 1.x to 2.x means the v1 API surface should not be assumed to carry over.

Gotchas and Tips

Quiet means silent to everything, including your own code. The biggest pitfall: caches, denormalised columns, search indexes, and outbound webhooks will not update. If a quiet write bypasses an observer, nothing tells you it did. Add an explicit post-batch refresh step, or you will find stale data days later.

Third-party/plugin hooks are the invisible casualty. If the meta writes normally trigger hooks that other code in the ecosystem depends on (very common in CMS-adjacent packages), quiet writes will make those consumers miss data entirely — with no error. Check whether the plugin/theme layer expects those hooks.

Quiet is not validation, casting, or dirty-checking. Assume a quiet save still runs your casts and accessors, but verify. And still check the return value / isDirty() — a quiet failure is quieter than a loud one.

Beta API churn is the real risk here. "Quiet meta updates" landed in beta.11 with no accompanying docs in the release note. The method name, whether it's a boolean argument, a fluent ->quiet() scope, or a separate method, may change in beta.12. Write a thin wrapper in your own codebase (e.g. a MetaWriter service or a trait method) so a rename in the package is a one-file fix rather than a search-and-replace across the app. Assert the behaviour in your own test that fails loudly if the semantics change on upgrade.

Debugging quiet writes. If a value appears not to persist, first confirm the write went through the model layer rather than a raw query builder call, then compare the quiet path against the standard path on a single record. Temporarily adding a log line inside the relevant observer is a fast way to confirm whether the quiet flag is doing what you think.

Watch the major-version gap. There is no stable 2.0 release and no published upgrade guide in the release note. Before adopting, read the 2.0.0-beta.1 entry (the initial v2 breaking-change commit) — that is where the real migration cost from v1 lives, and it is far more consequential than beta.11's single feature.

Extension points to check. Model events/observers, meta casts/accessors, and any config that gates hook dispatch. If the package exposes a global "disable hooks" config, avoid it — a per-call quiet flag is safer and easier to reason about than a global switch that can leak across requests in long-running workers (Octane/queue).

Bottom line for this release: beta.11 is a small, additive, developer-ergonomics feature — no deprecations or breaking changes signalled. It is useful if you do batch meta writes, but it does not change the overall recommendation: this package is beta software, so pin it, wrap it, and test the behaviour you depend on.