Support

Direct help for common BaseBuddy setup, access, mapping, editing, and deployment tasks.

Support/How to fix a field showing as read-only

How to fix a field showing as read-only

Understand why BaseBuddy marks fields read-only and when it is safe to update the mapping.

BaseBuddy shows read-only when it can read a value but should not write it yet.

Use this when a field appears in the editor but the control is disabled, marked read-only, or shown only as display text. The goal is to find out whether the field is intentionally protected, mapped to an unsafe write path, or blocked by permissions.

BaseBuddy editor with a mapped post open and post details in the sidebar
BaseBuddy editor with a mapped post open and post details in the sidebar

Why fields become read-only

The saved mapping is the runtime truth. BaseBuddy uses it to decide where a value is stored, what kind of value it is, and whether Save can patch only that storage target.

Read-only is often the safest correct result. It protects generated fields, unsupported shapes, incomplete relations, broad JSON paths, view-derived values, and fields the current member is not allowed to change.

CauseWhat to check
Unsupported storage shapeThe column, JSON path, array item, or computed value can be displayed, but BaseBuddy does not have a supported write mode for it.
Missing write pathThe mapping points at a value without enough information to patch the exact source, such as an incomplete JSON path or helper-row target.
Mapped as read-onlyThe field is intentionally configured as read-only in mapping.
PermissionsYour project role can view content but cannot edit that field, content type, author scope, or workflow state.
Unsafe mappingBaseBuddy cannot prove that saving would only change the intended storage target.
Relation or media shape not writableThe relation, media, or file value can be shown, but the join table, foreign key, storage reference, or list shape is not mapped to a safe write operation.

For more background, see How mapping works, Mapping fields and relations, and Safe editing model.

Do not force unsafe mapping

Do not make a field editable just to remove the read-only label.

If the source is generated, trigger-managed, view-derived, unsupported, missing write details, or part of a relation shape BaseBuddy cannot safely patch, keep it read-only until you know the correct write path.

Forcing an unsafe mapping can make Save update the wrong column, overwrite a larger JSON object, replace a list unexpectedly, or break assumptions in the app that owns the database.

Troubleshoot in order

Start with the field itself, then check mapping, then check permissions.

  1. Open the content item where the field is read-only.
  2. Note the field label and whether BaseBuddy says it is read-only or cannot be edited here yet.
  3. Open Settings.
  4. Open Mapping.
  5. Open the mapping section for the affected field, usually Open Posts mapping.
  6. Check the mapped source and write path.
  7. If the mapping looks safe, open Permissions.
  8. Check the affected member's role, explicit denies, author scope, and publish access if the field changes workflow status.
  9. Change only the smallest thing that explains the problem.
  10. Verify with one harmless edit before regular editing resumes.
Content mapping overview showing posts, authors, categories, tags, media, and files connected
Content mapping overview showing posts, authors, categories, tags, media, and files connected

Check the mapping

  1. Open project settings.
  2. Open the mapping area for the content type.
  3. Find the field that is read-only in the editor.
  4. Check the mapped table, column, JSON path, relation, media, or file source.
  5. Check the storage type and value kind.
  6. Check whether the field is explicitly marked read-only or unsupported.
  7. For relations, media, and files, confirm the writable source is mapped, not only the display value.
Posts mapping core fields with title, content, slug, redirects, excerpt, and featured image selected
Posts mapping core fields with title, content, slug, redirects, excerpt, and featured image selected

Use How to map a posts table, Projects and mappings, and Mapping fields and relations if you need to review what a safe source looks like.

Keep unsafe sources read-only

Leave the field read-only when the source is:

SourceWhy to avoid editing it
Generated columnThe database owns the value.
View-derived fieldBaseBuddy may not have a real table target to patch.
Trigger-managed valueYour database logic may be responsible for updates.
Unsupported typeBaseBuddy can display it but cannot safely write it yet.
Broad JSON or array sourceSaving could replace more data than the one field.
Incomplete helper-row mappingBaseBuddy may not know which helper row or value column to patch.
Ambiguous relationSaving could change the wrong foreign key, join row, or selected value.

Check permissions

If the mapping looks writable, check the member’s access next.

  1. Open project settings.
  2. Open the member’s permissions.
  3. Confirm the role or overrides allow editing content.
  4. If the field affects workflow status, confirm the member has publish access.
  5. If author scopes are enabled, confirm the member has access to this item’s assigned author.
Permission controls for a project member with role defaults and overrides
Permission controls for a project member with role defaults and overrides

Use Permissions and roles, How to customize permissions, and Permissions and teams when the field is writable in mapping but blocked for one member.

Fix the safest cause first

If you findSafer fix
Field was intentionally read-onlyLeave it read-only unless the database owner confirms it should be editable.
Wrong field sourceRemap the field to the correct table column or JSON path.
Unsupported typeChoose a supported source for editing, or keep the value display-only.
Missing relation write targetMap the foreign key, join table, or list source BaseBuddy should patch.
Missing media or file write targetMap the stored reference BaseBuddy should save, not just the public URL or preview value.
Missing permissionUpdate the member role or permission override, then test only that action.

Do not rename or reshape your existing content tables to make a field editable. BaseBuddy should follow your existing schema, not silently convert it into a different content model.

Verify after fixing

After changing mapping or permissions, test one harmless edit before regular editing resumes.

  1. Open one safe content item.
  2. Change one low-risk field, such as an excerpt, internal note, or draft-only text field.
  3. Click Save.
  4. Inspect the row in Supabase or your database client.
  5. Confirm only the expected mapped storage target changed.
  6. Reopen the item in BaseBuddy and confirm the value still displays correctly.
Editor with one dirty field and Save enabled
Editor with one dirty field and Save enabled

Avoid testing with publish status, archive actions, relation changes, media replacement, or large JSON fields until one simple dirty-field save works.

For the full first-edit checklist, see How to safely edit your first post.