0.0.2-alpha.68

The Builder's ALTER generator wrote ALTER TABLE … DROP COLUMN IF EXISTS, a form MySQL does not accept (MariaDB does). On MySQL the drop failed, the column stayed, and a Required field's column, NOT NULL, refused every later entry, both for collections and for Singles. The same statement went into the migration file, where nextly migrate failed on it. PostgreSQL keeps IF EXISTS; MySQL and SQLite get the plain DROP COLUMN.

Columns that an existing MySQL install kept from fields removed before this fix are not dropped by it: a save drops only the columns of the fields it removes. They stay, with their data, until removed on purpose.

A collection save in the Schema Builder now applies whole or fails whole on PostgreSQL and SQLite, and says why on every database.

• Before anything runs, the save checks the entries: a field made Unique over repeated values, a new Unique field whose backfill would repeat, and a text field narrowed below a value an entry holds are refused, naming the field. A refusal never shows a stored value.
• The migration runs before the file and the registry are written. On PostgreSQL and SQLite it runs in one transaction, so a refusal changes nothing. On MySQL, which commits each schema statement, the refusal says which statement stopped it. Saving again finishes the change for what such a refusal most often leaves behind: a column already added or already removed, Draft/Published already turned on or off, a plain or unique index already created or dropped, and a translated field's companion column already added.
• Turning Unique on or off for an existing field now creates or drops its unique index. Before, only the registry changed, so a field could be recorded unique while the table accepted repeats.
• A new field whose name matches a column of another type already on the table is refused, naming the column, instead of being recorded over it.

Postgres and SQLite were not affected.

What a MySQL install saw, in every release since localization transitions were recorded (2026-07-31):

• Turning localization off on an entity copied nothing back onto its main table, during db:sync, dev reloads and nextly migrate's companion pass. The site went back to the values the entity had before it was localized, and edits made while it was localized looked lost. They were not: they are intact in the entity's translation table (dc_<slug>_locales for a collection), which is left in place.

• Re-enabling localization after a disable did not refresh the translation table, so edits made while it was off stayed hidden.

• A first enable copied its content, but every later pass reported that the transition was held by another process. Writing translations was not blocked.

Before you start the upgraded version, save any edit made directly to an affected entity's main table since you turned its localization off. The first nextly db:sync, dev-server start or nextly migrate after upgrading restores the translation table's values onto the main table, replacing those edits. To list the rows where the two differ, run this for each entity whose localization you turned off, with its slug, its default locale and one comparison per translated field:

SELECT m.id, m.updated_at, m.title AS on_main, l.title AS in_translations
FROM dc_<slug> AS m
JOIN dc_<slug>_locales AS l ON l._parent = m.id AND l._locale = '<default locale>'
WHERE NOT (CAST(m.title AS BINARY) <=> CAST(l.title AS BINARY));

The binary cast on both sides makes the comparison exact and keeps it null-safe: under MySQL's default collation, <=> alone takes Foo and foo for the same value, so an edit that changed only letter case or accents would not be listed. For an entity defined with timestamps: false, leave out m.updated_at: it has no such column.

A row whose updated_at is later than the disable was edited on the main table since, and the upgrade replaces it with in_translations. Every other listed row is an edit made while the entity was localized, which the upgrade brings back. updated_at moves only with saves made through Nextly: a row changed outside it (from a SQL client or a script) can keep an older updated_at, so if anything wrote to the main table that way, judge its rows by their values, not by the date.

Recovery, after upgrading: run nextly db:sync (or start the dev server, or run nextly migrate). For an entity whose localization was turned off, the earlier pass never recorded the restore as done, so this pass restores the default language's values from the translation table onto the main table. A stuck first enable settles on the same pass.

A migration file that turns localization off was never affected: its own statements restore and archive before the translation table is dropped.

Before, every such client shared one bucket per route, so one visitor spending the auth budget refused the route to all. Now each request counts against the identity the route's new, optional limitKey names, at the auth budget, under a ceiling of 100 times that budget that only the plugin's own auth routes share. A route without a limitKey is bounded by that ceiling alone, and the server names it at startup. Core's sign-in and other plugins keep their own ceilings. Auth routes are no longer listed in the startup warning about routes sharing one limit.

On a plugin's rateLimit: "auth" route, the body was read after the ceiling but charged at the time the request began, so a caller holding several bodies open longer than the window could make each charge land at a time already expired, and spend an identity's budget more than once. The route now spends the plugin's ceiling on arrival, before its body is read, so the ceiling also bounds how many requests a caller can hold open, and charges the identity once the body is in. Without a shared store, the ceiling place a request spent moves with its charge, so the two still expire together; core's token routes and strategy-keyed sign-ins are charged the same way.

The once-per-process warning about proxy client-address headers that could not be used also now says how a plugin's auth route counts such requests: by the identity its limitKey names, or against one budget its requests naming no identity share, under that plugin's own ceiling, or by the ceiling alone without a limitKey.

Before, the challenge view showed only a short message.

When the page is open at an address the app does not accept, for example 127.0.0.1 for an app at localhost, it names both addresses and links to the same page at the app's own. Before, the form looked unchanged. The auth routes' 403 CSRF_FAILED answer now carries data.reason ("origin" or "token") and, for an origin, data.appOrigin; what they accept is unchanged.

GET /api/releases/:id/readiness and nextly.releases.readiness() report each document's hard problems (no author, an author who is gone or may no longer publish or unpublish it, a document that is gone, a collection or Single without a draft/published lifecycle or whose translations lack a per-language status, unreleased work held in another language, a document going live that fails validation or edits a field its author may no longer write) and soft ones (another scheduled release holds it, and which one wins). Every document is checked, however many the release holds. Scheduling, Publish now and adding a document to a scheduled release are refused while a hard problem stands, as a 409 CONFLICT naming each problem in data.problems, alike over REST and the Direct API. A document coming down is never validated. PATCH /api/releases/:id/members/:memberId and nextly.releases.changeMemberAction() switch a document between going live and coming down, checking the new action as the document's author in a scheduled release. The blocking reasons are now derived from the same checks. All of this is experimental. Publish now judges each member by its author, as the scheduled run does.

A release's readiness check now judges each document's own write before the moment. A status the author's field rules would not let them set is reported as FIELD_NOT_PERMITTED rather than refused when the release runs, and a document taken down with a pending change is judged on that change, as the takedown folds it in. The checks also read each collection's stored documents and translations once per batch.

A related document unpublished or removed since no longer makes an unchanged relationship read as edited, and a failed read of the stored ids fails the check instead of reading as an empty relationship. - For a localized collection, the live document the pending change is compared with now carries the default language's stored translations, as the write's does. An unchanged protected translation no longer reads as edited.

update-content-releases lets a person change a release's title and description in any state, through PATCH /api/releases/:id or nextly.releases.update(). delete-content-releases lets a person delete a release that never ran, with its documents, through DELETE /api/releases/:id or nextly.releases.delete(): a draft, or a release cancelled before it was ever scheduled. Every other release is refused with a conflict whose data.reason says why: a scheduled or stopped release (committed) can be cancelled to call it off, and is then kept; a published one (published) stays as the record of what went live; and a cancelled release that was ever scheduled (was-scheduled) is kept as a record too, because nothing stored says whether it began to run before it was called off. The delete answers with the release as it was. Each rename and deletion is recorded in the activity log, and the capabilities sent with every release gain update and delete, so the admin can offer only what the caller may do. All of this is experimental until the releases redesign is complete.

An existing installation receives both permissions the first time it boots, granted so that nobody gains or loses anything: super-admins hold both, every role holding create-content-releases gains update-content-releases, and every role holding publish-content-releases gains delete-content-releases. The grants are made once, when the permissions are created, so a permission an administrator later takes from a role is not given back on the next restart.

The collection was read from anywhere in the URL, query included, and every name opened a counter of its own, so one address could rotate a query value or an invented collection slug and never meet its budget, and invalid API keys could be looked up past their bound the same way. The collection now comes from the path alone, and only a collection with limits of its own in rateLimit.collections keeps a separate budget; every other request counts against the address's one budget.

A signed-in session spends a budget of its own, five times the per-address budgets by default (rateLimit.sessions), so the admin's parallel page loads no longer need an exemption. An API key that resolves spends its own apiKeys.rateLimit budget, counted once per request, and a plugin's signed-in people each spend a budget the size of a session's. Requests carrying neither from an address the server cannot resolve share a ceiling of ten times the per-address budgets (rateLimit.unresolvedCeiling), which never refuses a session, a key or a sign-in. Invalid API keys and unresolvable plugin people are bounded before the next lookup. An app that relied on the old exemption can pass the deprecated defaultSkipAdminApi as rateLimit.skip; a later release removes it.

The limit's defaults now have one source, 100 reads and 30 writes a minute per address, which is what every app configured through defineConfig already ran on. A limiter built with no values used a second copy of 600 and 120; it now uses the same 100 and 30. That narrows only code that reaches the limiter without a sanitized config: createRateLimiter() called without readLimit or writeLimit, and createDynamicHandlers() created without a config. Pass the limits explicitly to keep the old numbers.

A field badge reads "no longer localized". - A change that can't be made in one save is refused with the steps to take: a Required field can't stop being translated in the same change, so the dialog says to turn off Required and save, turn off Localized and save, then turn Required back on. - The command that restores the archived values (nextly i18n:restore) is shown on one line, with a copy button. - The dialog's Save button now uses the primary style rather than the destructive red, which it used for every change.

When the client's address cannot be read, the sign-in rate limit then keys that strategy's sign-ins on what it reads, such as a username or an OAuth code, so rotating the email in the body no longer buys a fresh budget. A strategy without limitKey keeps sign-ins keyed on the email they carry, as before, and the server names it at startup while the limit is on.

The top row holds the way back to the collection's list at the left and every action at the right, with History first. The title has a line of its own below at full width, so it is no longer cut to a few words wherever the actions take the width, and the save state moves to a status line under it. Save draft, Unpublish and the other secondary document verbs keep their words at every width: they draw no icon, so at narrow widths they used to leave an empty bordered button. On a phone, History and the preview move into the document's menu and the panel toggle goes, so the actions keep to one row. What each control does is unchanged.

Before, it opened over the entry form. A reload keeps the author in the builder, a link to it can be shared, and Exit editor goes back to the page's form. The admin holds the page's soft lock, the offer to restore unsaved work, and the question before leaving with unsaved changes. Saving a pattern no longer saves the page as well. If a colleague takes the page over, the author's unsaved edits stay in their form until they take it back.

A page that has never been saved has no address yet, so its Page Builder card asks the author to save it first. The Page Builder edits the default language: opened from another language's edit screen, it opens the default one, and the card says so.

Compatibility. The Page Builder now opens only for a blocks field at the top level of a collection or a Single, including one inside an unnamed group.

• Who is affected: a site that declares a blocks field inside a named group or a repeater. That field's card still shows the page, but offers no way into the builder, and startup logs a warning naming the collection and the field. The warning covers fields declared in code; for a collection made in the Schema Builder, the card is what says it.

• What to do: move the field to the top level of its collection or Single to edit it visually, or keep it where it is until nested fields are supported.

The builder is a document view at the builder address on every document with a top-level blocks field, so another plugin declaring a document view at builder is refused at startup, naming both plugins.

On MySQL the creation time, the archive time and the reading of it are all in the session's time zone, which may differ each time, so a narrower margin could give an older entity's translations to a newer one with the same slug. Rows inside the window stay unresolved: kept, reported by a restore and restored by naming their kind.