Externa Core 1.2.1 — field rename drafts & deps

21 October 2026 — Externa Core v1.2.1 (hotfix from hotfix/1.2.1, PR #223). A notable patch: content-versioning correctness plus dependency security bumps already listed in the public release notes. GitHub Release v1.2.1.

Prefer PHP 8.4.27+ or 8.5.12+ on the host (composer still declares ^8.4).

Who should upgrade

Everyone on 1.2.0 who renames collection fields while drafts or revisions exist — and anyone whose npm audit --audit-level=high was unclean on the admin frontend lockfile.

What fixed

Field renames no longer drop draft/revision values

Renaming a field no longer drops its value from pending drafts and older revisions (#218). Publish-time behavior is unchanged.

Dependency security (public GHSAs)

The release notes document lockfile bumps so npm audit --audit-level=high reports 0 high/critical, including:

• follow-redirects 1.16.0 → 1.16.1
• vite 8.3.0 → 8.3.5 (package.json range ^8.3.5)
• brace-expansion 1.1.18 → 1.1.21 (dev/eslint path)

We describe only what the public release already lists — no unpublished advisories.

Upgrade steps

1. Back up the database.
2. Deploy v1.2.1 (git tag or ghcr.io/qiick-io/externa-core:1.2.1).
3. Install and clear caches:

composer install
npm ci && npm run build
php artisan externa:upgrade

4. Right after deploying 1.2.1, and before the scheduler runs or anyone publishes, repair drafts/revisions that still hold a pre-rename field key:

# dry-run (default, no writes)
php artisan externa:repair-renamed-field-drafts

# apply
php artisan externa:repair-renamed-field-drafts --apply

Mappings come from CollectionField activity-log rename history. For orphans without history, pass --map=collection:old=new (slug or id; repeatable). The command never overwrites a value already under the new key. Keys reported as unmappable belong to deleted fields and can be ignored.

5. Restart queue workers / Horizon as usual.

Sources

• GitHub Release v1.2.1
• Upgrade · Content versioning · Changelog