Using a tag named "c" (it's not possible)

I have a tag called c that I want to delete but tags/c redirects to 404 so there seems to be no way of deleting it…

I have a tag that has never been used, and I can delete it:

Is there more to the story?

I’m not sure who you’re replying to* (and hence whose story you are referring to) but if it’s me, tags/not-used also gives me the oops page.

*This made sense when this was still part of a larger topic.

Now I’m very confused!

If you don’t have a tag named “not-used”, then yes you will get the oops page. I have one, so I can visit “tags/not-used” and it will allow me to change it and delete it. Did you create a tag named “not-used”?

LOL. Okay, so you have a tag called “not-used” and you can delete it and that is how it’s supposed to be.

Now I have a tag called “c” and I cannot delete it. (I also had some other tags which I was able to delete.) To be more precise, I cannot acess the tag’s page (at tags/c) because it redirects to 404 and since the delete button is on that page, I cannot detele the tag.

And, no, the tag is not used on any topic:

Oh I see. So command and test are fine, but it’s the “c” that’s the problem. That’s because it conflicts with a route, like /tags/c/category-name/tag-name which intersects a category with a tag.


Oh, I see. So there is no way of getting rid of the tag via the web-ui?

In any case: shouldn’t the creation of such tags be prevented in the first place?


I would say no. It’s a very rare use case. Creating a tag named « c » and wanting to delete it. Sounds like a lot of special edge case code to handle something almost no one will ever run into.

Is c the only case where this can occur?

1 Like

Well, yeah, if it’s only this single case, yes. I thought there might be others (see also @Stephen’s question).

No, that’s not relevant here. Even if you don’t want to delete it, the tag page won’t work.


That’s my point - if there’s any chance of a namespace collision then we should have a list of prohibited tag names, even if it’s only validated within the page.


I don’t know if it would foobar routing, but maybe “u”?

Technically these could be an issue:


In practice, only c and personal_messages will have the bug discussed here. I still think it has reasonably low chances to happen and we should live with it as the fix is not trivial.

While the initial fix would be as simple as:

  validates :name, presence: true,
                   uniqueness: true,
                   exclusion: { in: %w(c personal_messages) }

We would then have to update the front code to display the correct error in this case. Which is not that easy given that for example when done through /tag_groups we don’t handle correctly a validation error.

To sum it’s not impossible but would require some work, what do you think @neil ?


Agreed that this is low priority.



Just so that you know it’s not so low probability: we had exactly the same issue, and I think having a tag named c is probably quite natural in development related areas, after all, C is one of the most used programming languages…

And once it’s created, it looks it stays forever, and people are using it…

I don’t understand well enough the original issue to propose a less expensive solution though…

1 Like

Use c-lang just like they currently use go-lang

1 Like

Sure, I already suggested something similar on our instance. And all would be good if we had known this issue when starting to use discourse.

However we did not, so we created this bogus c tag, it’s there, some people use it, and we don’t seem to be able to get rid of it… Even a dirty trick like a magic url that would allow to rename this tag to anything so that we can get rid of it would look like a perfectly good enough solution to me :hugs:

1 Like