Gophenberg 0.15.0

Check GOPHENBERG_DATABASE_URL before updating. An @ inside the database password must now be written as %40, or the server does not start. One migration runs on the account tables and changes no content.

A field group that still stores fields inside another group's container can now be deleted. GOPHENBERG_FIELD_DEPTH sets how deep fields nest, a theme that never answers no longer stalls its start, and a themes folder the server cannot write to is refused with a reason. In the editor, the Add button turns off at the row limit and a Flexible content field with no layouts says so. The theme kit is unchanged.

See Updates and backups.

Gophenberg 0.14.0

Moving a Section or a Repeater to another field group now takes the fields inside it along. One migration repairs sites where earlier moves left fields behind, and it deletes nothing.

A failed answer is never cached any more, and an answer to a signed in account is never kept by any cache, plugin routes included. The theme kit is unchanged.

See Updates and backups.

Gophenberg 0.13.0

A Relation field now stands inside a Section, a Repeater row or a Flexible content layout, so each row points at its own items. Themes read one with heldRows and relatedItems.

What an item points at now lives with the item. One migration copies existing relations across on first start, and the theme kit is unchanged.

Rolling back reads fine, but a relation changed while rolled back is lost on updating again. See Updates and backups.

Gophenberg 0.12.0

Four field kinds arrive. Flexible content builds a page from rows that each pick a shape. Linked from lists the items pointing at the one you are editing. Link holds an address, the words it is read under, and whether it opens in a new tab. Color offers a color control. A Gallery now takes several files at once, keeps the order you pick, and can bound how many it holds.

Plugins now read the same values themes read, as plain JSON.

Theme kits 0.13.0, 0.14.0 and 0.15.0 work on a released server from now on. On an older kit a Linked from list shows up among the relations, so rebuild on 0.15.0.

Behind a shared cache, one reader's language no longer reaches another.

Updating runs two migrations. Back up the database before the first start. Rolling back to 0.11.0 deletes nothing, but that release cannot edit the new kinds.

This release serves themes built on @gophenberg/astro 0.15.0, and still answers 0.9.0 through 0.14.0.

Gophenberg 0.11.0

Custom fields grow up in this release. A field now carries settings saying what its value may be, and the editor names a value outside those limits as you type rather than waiting for the save. New kinds arrive with them: a choice field offering the answers you declare, text variants, a slider, and a gallery. A media field serves the file itself rather than an id, ready for a theme to render without a second request.

Fields can hold fields. A Section bundles them under one name, a Repeater holds rows of them, and either can hold more of the same as deep as a page needs.

A field can also wait until another says so. Give it rules naming the fields beside it and it shows only while they hold, judged the same way in the browser and on the server. What a hidden field already holds stays where it is, so turning the switch back on brings the value with it.

Mark a field In list and it becomes a column in the content table, and a switch or a choice becomes a filter above it. Listings narrow by a value through a field[key] parameter on both the administrative list and the public one, and the theme kit reads the same terms.

Definitions travel between sites. Export the types, groups and fields one site declares and import them into another. A plugin can declare the types and fields it needs, and the site can take them over as its own.

The listing page size, the picture quality, the theme timings and the upload cap are all configurable now. Field definition edits no longer overwrite each other.

Updating runs seven migrations. Back up the database before the first start, and read what a rollback costs in the self-hosting guide before going back past this release, because rolling back deletes every Choice, Section and Repeater field, every field standing inside another, and the settings all of them carry.

This release serves themes built on @gophenberg/astro 0.12.0, and still answers 0.9.0, 0.10.0 and 0.11.0.

Gophenberg 0.10.0

Custom fields now live in field groups. A group holds a bundle of fields and carries location rules saying which content it appears on, so one bundle can reach several types and a type can draw fields from several groups. The admin gains a Field Groups screen with a rule builder, group scoped field management, and a control that carries a field into another group with the values it holds. Where two groups meet on the same field key the screen names the overlap and marks the group whose field is not shown.

Updating runs one migration, which carries the fields each type declares into a group placed on that type. Every type serves the same fields it served before, proven byte for byte against a fixture captured before the migration. Back up the database before the first start, and read what a rollback costs in the self-hosting guide before going back past this release.

This release serves themes built on @gophenberg/astro 0.9.0, unchanged from the last release.

Gophenberg 0.9.0

Theme kit on its own line

The theme kit now carries its own version, released separately from Gophenberg itself, and a site refuses a theme built against a kit it does not serve rather than answering a broken page. This release serves kit 0.9.0, published as @gophenberg/astro@0.9.0. Build your theme against that version before upgrading.

Fields you can actually manage

Fields of a content type can be reordered, marked required, and pointed at a single target, all from the admin. The field endpoints now refuse attributes they do not understand instead of accepting a change and silently ignoring it.

Translations travel both ways

Catalogues written here reach the translation platform, carrying their fuzzy flags so reviewers correct a machine answer rather than facing an empty box. The catalogue gate reports how much of each language still waits for review without failing the build on it.

An administrator locked out by an upgrade

An account seeded before the roles cycle held no role, so every privileged check refused it and the admin quietly lost user management, content types and themes. Running the seed now carries such an account across, and gophenberg grantrole -role admin repairs an installation whose accounts all predate roles.

Error vocabulary

Refusals are named consistently across the API and the admin, and reader facing messages are answered in the reader's own language.

Upgrading

Publish or rebuild your theme against @gophenberg/astro@0.9.0 first, since a site running 0.9.0 will refuse a theme declaring an older kit. If your administrator account predates the roles cycle, run the seed or grantrole once to restore its privileges.

Gophenberg 0.8.0

The thing an account holds is now called a role, not a rank. Nothing about who may do what has changed, only the word. An admin still runs the site, an editor still works everyone's content and media, and an author still works only its own.

The word changes everywhere it was visible: the grantrank command is now grantrole, the -rank flag on createadmin and on the grant command is now -role, the column holding it is now auth.users.role, and the refusal an unprivileged request answers with is now role_insufficient. No old name is kept as an alias, so a script passing -rank is rejected rather than ignored.

The authentication bricks were renamed first and this release adopts them: gouncer v0.3.0, authkit v0.9.0, authkit/postgres v0.7.0 and @gopherium/react-auth 0.6.0.

Upgrading

Read this before starting the new version. Two steps, in this order, and both only on a site that already ran an earlier release.

First, rename the column. Earlier versions stored the role in a column called rank. This release ships the rename as an edit to the migration that creates it, which means a database that already ran the old migration keeps the old column name and no migration will ever correct it. Nothing detects this. The site starts, reports no error, and then refuses every login. Check which name your database has:

psql "$GOPHENBERG_DATABASE_URL" -tAc "select column_name from information_schema.columns where table_schema='auth' and table_name='users' and column_name in ('rank','role');"

If it answers role, or nothing at all, there is nothing to do and you can start the new version. If it answers rank, rename it once, first:

psql "$GOPHENBERG_DATABASE_URL" -v ON_ERROR_STOP=1 --single-transaction \
  -c "ALTER TABLE auth.users RENAME COLUMN rank TO role;" \
  -c "ALTER INDEX auth.users_rank_idx RENAME TO users_role_idx;"

Both renames happen together or neither does. Every account keeps what it held.

Second, give a role to the accounts that hold none. Accounts made before roles existed hold none and can do nothing until one is given:

GOPHENBERG_DATABASE_URL=... gophenberg grantrole -role admin

It only touches accounts holding none, so running it again changes nothing.

Users and signing in covers both steps in full.

Gophenberg 0.7.0

Every account now holds a rank, and the rank decides what it may do. An admin runs the site, an editor works everyone's content and media, and an author works only its own. Screens a rank cannot reach are hidden from the menu and refused by the router, the administration routes answer an admin alone, and the server lets an author change only the work it wrote.

Plugins can read the signed-in session and ask what capabilities it holds, so a plugin screen offers only what its caller can use.

The translation pipeline moved out into the @gopherium/gottext brick and nothing is vendored any more. The sync gained a rule it lacked: a translation once set is never removed, so an export that holds an answer empty or drops a plural form no longer erases the one the repository holds.

Upgrading

Accounts made before ranks existed hold no rank and can do nothing until one is given. Run this once against your database:

GOPHENBERG_DATABASE_URL=... gophenberg grantrank -rank admin

It only touches rankless accounts, so running it again changes nothing. Pick the rank those accounts should have. Where the existing accounts are the people running the site, admin is the usual answer.

Users and signing in covers the ranks and this command in full.

Gophenberg 0.6.0

Gophenberg speaks the reader's language. Every string the admin and the public site show now lives in a gettext catalogue, a reader picks the language they read in while the site picks the one it answers in, and translators work on a hosted platform rather than in Git. Spanish ships as the first locale, complete at 358 messages.

• A reader's own language wins over the site default, which wins over the browser's preference
• A Language screen where a reader picks their language and an administrator sets the site's
• 358 translatable messages across the admin, the public site and the account screens
• The public site follows the site default, dates included, with month names and their order as catalogue entries rather than Go constants
• Refusals carry a stable code, so a failure is explained in the reader's language instead of echoing the server
• Translation happens on POEditor, and a weekly job carries finished work back in one batch

Upgrading

One migration runs on start, 00011_create_user_settings. Back up the database before the first start on this release. Public addresses do not change shape.

Themes move to @gophenberg/astro 0.6.0, which carries no interface change. Account screens are served by @gopherium/react-auth 0.4.0, which now ships its own text domain and catalogue.

Translating

Spanish is complete but every entry is marked unverified, the gettext fuzzy flag, because it was drafted rather than written by a native speaker. It renders throughout while that review happens. Any language can be added, and no Git is needed: https://poeditor.com/join/project/WHdsSyegwJ