Support

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

Support/How to map tags on BaseBuddy

How to map tags on BaseBuddy

Map the tag fields, arrays, or relation tables your existing schema already uses, then verify that tag saves only touch that storage.

Use this guide when your posts already have tags and you want BaseBuddy to show and edit them safely.

BaseBuddy does not install a standard taxonomy schema. It maps the tag shape your database already uses, then reads and writes through the saved mapping. If the storage shape is unclear, generated, trigger-owned, or unsafe to patch, keep tags read-only or unsupported until you know the correct write path.

Before you start

Make sure your posts mapping is already saved and one post opens correctly in the editor. Tags are easier to verify after the basic post fields are working.

BaseBuddy mapping settings showing content tables and mapped fields
BaseBuddy mapping settings showing content tables and mapped fields

If you are still mapping the main content table, start with How to map a posts table.

Identify your tag shape

Check how your app stores tags today. The right mapping depends on the existing storage, not on the field name.

Existing shapeCommon exampleHow BaseBuddy should treat it
Join tablepost_tags(post_id, tag_id)A multi-select relation through the existing join table
Single tag foreign keyposts.tag_id -> tags.idA single tag selector
Value matchposts.tag_slug -> tags.slugA selector that stores the matched value, such as a slug
List columnposts.tag_ids, posts.tag_names, posts.tags, posts.keywordsA list value, usually edited as the whole mapped list
JSON list or objectposts.meta->tags or a tag object columnEditable only when the mapped JSON value is the exact tag value BaseBuddy should write
Derived or trigger-owned tagsView output, generated values, trigger-maintained rowsRead-only or unsupported until you have a safe write path

Do not create new tags or post_tags tables just because a guide uses those names as examples. Use your real table, column, list, or JSON shape.

Map a join-table tag relation

Use this path when each post can have many tags through a table such as post_tags, article_tags, or entry_topics.

  1. Open the project in BaseBuddy.
  2. Open Project Settings -> Content Mapping.
  3. Select Open Posts mapping.
  4. Continue to the Tags step.
  5. For the tag source, choose Stored in another table.
  6. In Connection path, choose the existing connection table.
  7. Set Connection table to the table that connects posts to tags.
  8. Set Item column to the column that points at the tag record, such as tag_id.
  9. In Tag fields, map the tag record fields editors should see, usually ID, Name, and optionally Slug or Description.
  10. Continue through the mapping wizard.
  11. When BaseBuddy asks Save content mapping?, review the change and select Save mapping.

The post-side column should point at the post row. The item column should point at the tag row. If those are reversed, BaseBuddy may show the wrong tags or write the wrong join rows.

Posts mapping core fields step with the article table fields selected
Posts mapping core fields step with the article table fields selected

Map tags stored on the posts row

Use this path when the tag value lives directly on the posts table.

  1. Open Project Settings -> Content Mapping.
  2. Select Open Posts mapping.
  3. Continue to the Tags step.
  4. Choose the existing tag column from the posts table.
  5. If it is a foreign key, confirm the target tag table and display field.
  6. If it is an array or list column, confirm the mapped value is the whole tag list BaseBuddy should replace on save.
  7. If it is JSON, choose the JSON shape only when that mapped value is dedicated to tags.
  8. Save the mapping.

For list and JSON storage, be extra careful with broad fields. If metadata stores many unrelated values and tags are only one nested part, do not map it as an editable tag value unless the write path is explicit enough to avoid replacing unrelated JSON.

Map readable tag fields

When tags point at a separate tag table, map the fields that make the selector understandable.

Tag fieldGood choices
IDid, primary key, or the stable unique value your relation stores
Namename, title, tag_name, label
Slugslug, handle, key
Descriptiondescription, summary, details

Use the stable ID or unique value for the relation itself. Use the human-readable field for display so editors do not have to choose from raw IDs.

Verify one tag save

Test with one known post before editors rely on the mapping.

  1. Open Posts.
  2. Choose a draft, internal test post, or another row that is easy to inspect.
  3. Open the post and find Tags in the editor or sidebar.
  4. Add or remove one tag.
  5. Select Save.
  6. Inspect the same post in Supabase or your database client.
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

The database change should match your mapped shape:

ShapeGood result
Join tableOnly the mapped rows for that post change in the connection table
Single foreign keyOnly the mapped tag column changes on the post row
Value matchOnly the mapped stored value changes, such as the tag slug
List columnOnly the mapped list column changes
JSON tag valueOnly the mapped tag JSON value changes

Normal Save should not publish, unpublish, archive, rewrite unrelated fields, create a new taxonomy schema, or convert one storage shape into another.

Safe first edit with one title change and Save enabled
Safe first edit with one title change and Save enabled

For the broader first-edit checklist, use How to safely edit your first post. For the underlying model, see Safe editing model.

Common issues

If tags do not appear, confirm the tag table or tag column is visible to the database user BaseBuddy uses. BaseBuddy cannot map tables or columns it cannot read.

If the wrong tag label appears, check the Tag fields mapping. The relation may be correct, but the display field may point at an ID, slug, or unrelated column instead of the readable tag name.

If saving tags changes unrelated rows, stop and review the relation direction, connection table, item column, and post-side column. A join-table mapping should only replace the mapped tag rows for the current post.

If the Tags field is read-only, check whether the shape is derived, trigger-managed, missing a write target, or too broad to patch safely. Use How to fix a field showing as read-only before trying to make it editable.