# A prefix is a tag

2026-08-08. Asked for directly:

> "Also need a way to edit tags as well. Also having tags and prefixes in the
> Admin is redundant. Make it where the tag can be used as a prefix like in
> Invision."

and then, clarifying which "tags" were meant:

> "Tags in posts is what I am meaning."

---

## Two things were asked for and they are not the same thing

**One.** A topic's tags cannot be changed after it is posted. The tag picker is
on the create screen and nowhere else — so a tag chosen in haste, or a topic
that turns out to be about something slightly different, is stuck that way
forever. There is no screen anywhere that edits a topic's tags. (Tags
themselves *can* already be edited in the admin, which is why the request read
oddly at first; what is missing is editing the tags **on a topic**.)

**Two.** Tags and prefixes are two admin screens, two tables and two pickers
for what an operator experiences as one idea: a coloured label on a topic.

## Why they really are the same thing

Put the two rows side by side and the duplication is embarrassing:

| | `prefixes` | `tags` |
|---|---|---|
| name | ✅ | ✅ |
| colour | ✅ | ✅ |
| position | ✅ | ✅ |
| topic_count | ✅ | ✅ |
| limited to a forum | ✅ | ❌ |
| slug, description, icon | ❌ | ✅ |
| how many a topic gets | one | many |

A prefix is a tag with two extra properties: it may be limited to one forum,
and a topic has at most one of it. Everything else is the same columns holding
the same kind of value, maintained through two admin screens that look almost
identical.

So: **one table, `tags`, and a flag.** A tag marked "can be used as a prefix"
turns up in the prefix position; every tag turns up in the tag list. The
operator manages one thing.

## What a prefix means, kept

Dropping the concept would be the wrong simplification. A prefix is not
decoration — it is the label people scan a forum by, which is why it sits before
the title and why there is only ever one. Keeping the flag keeps that:

- **At most one per topic.** `topics.prefix_id`, unchanged, now naming a tag.
- **Optionally limited to a forum.** A support forum's "Solved" has no business
  being offered in Off-topic.
- **Chosen from the tags marked for it**, not from all of them, so a board with
  forty tags does not offer forty prefixes.

## 🚨 What this note is careful about

**The prefix picker must not become the tag picker.** They look similar and
they are not: one is a single choice from a small curated list, shown before
the title; the other is a multiple choice shown under it. Collapsing the *data*
is the point. Collapsing the *controls* would be a worse composer.

**`prefixes` has rows on somebody's site even though it has none here.** Local
development has fourteen tags and zero prefixes, and it would be easy to write
a migration that assumed that everywhere. It converts instead: every prefix
becomes a prefix-capable tag, every `topics.prefix_id` is remapped to the new
tag's id, and only then does the old table go. A site that had prefixes keeps
them, in the new place, still on the same topics.

**Editing tags on a topic belongs on the screen that already edits the topic.**
Editing the first post of a topic already lets you change its title — because
the first post *is* the topic in every way a reader cares about. Tags and the
prefix go on that same screen rather than a new one. A second screen would mean
two places to look for "change this topic", and the one somebody found first
would be the one missing what they wanted.

**Who may change them is the same question as who may edit the post**, and it
is already answered — the author inside the edit window, and moderators. No new
permission, because "can change a topic's tags but not its title" is not a
distinction anybody has ever wanted.

## What this note does not decide

- **Whether members may make tags**, rather than choosing from the operator's
  list. Invision allows it as a setting; it is a moderation question more than
  a feature question, and nobody has asked.
- **Whether a tag can be required in a given forum.** Frequently wanted on
  support boards ("every topic must say which version"), and it needs a story
  for what happens to the topics posted before the rule.
