Proposal to remove /c and /t prefixes from URLs

(Anton) #1


The number of categories is always limited in contrary to the number of topics.
Why not to put category name one level upper in the URL?

So, instead of /c/name we would have /name. I realize using the c prefix was intentional. But why? Would like to find out more about the reasoning behind this decision.


If the topic URL structure is always the same, and there are no other system pages that look like /something/<id>, why do we need the /t prefix for topics at all?

Existing top-level names

We have just a few top-level names like /admin and /logs, but would not it make sense to prefix them instead? With a dash or an underscrore or whatever:


The idea is just to make URLs even a bit shorter. I’m not sure I understand why do we need /t and /c in them. If you know why it is so, please share you knowledge.

(Jeff Atwood) #2

Those are needed for routing. Without those, the route matching semantics become very complex.

Changing them at this point would require months of difficult engineering work. It’s much simpler for the code to see

  • this URL contains a /c therefore it is a category
  • this URL contains a /t therefore it is a topic


  • is this a category word, or another top-level route?
  • does this URL contain a string of sufficient complexity, or a number of sufficient length in the correct location, to be routed somewhere else?

As you yourself noted, something like

suddenly becomes problematic… is that a category?

(Anton) #3

I though distinguishing between different kinds of URLs would be dead simple:

If URL starts with /string/number - it’s a topic
If URL starts with /string - it’s a category
If URL starts with /x/ - it’s anything system-wide like admin, logs etc. (choose x - it can be _ or - or something like that)

Am I missing something?

(Jeff Atwood) #4

Anton, I think you have “Shit’s Easy Syndrome”. You can read a little about it here :wink:

VPs have what my brother Mike refers to as “Shit’s Easy Syndrome”.

You know. As in, shit’s easy. If it’s easy to imagine, then it’s easy to implement. Programming is just turning imagination into reality. You can churn through shit as fast as the conscious mind can envision it. Any programmer who can’t keep up is an underperformer who needs to be “topgraded” to make room for incredible new college hires who can make it happen, no matter what “it” happens to be, even if they have to work 27 hours a day, which of course they can because by virtue of being new college hires, they have no social lives and no spouses or significant others, and they probably smoke a lot of crack from being in the dorms so they can stay awake for weeks at a time.

(Anton) #5

My level of English does not allow me to fully understand what that syndrome means, unfortunately. At least hope it’s not offensive, but almost sure it’s pretty ironical.

Anyway, would “permalinks” do the job? Or are they uni-directional only? I mean, will category links change to non-c versions if I add permalinks?

(Sander Datema) #6

You’d be lost with his one if the topic ever moves to another category. All links to it would be 404.

(Michael - #7

What if my category would be named x ? The URL would be /x/ which is reserved for system things.

(Anton) #8

x is an indicator character. It can be something less useful, e.g. _. Yet, I can’t even imaging naming a category x.


(Felix Freiberger) #9

I don’t really see the point of this change. The goal for these URLs is not shortness, but readability (otherwise, dropping the slug would be an obvious and easy improvement). And quite honestly: For readability, I like the /t/ and /c/. Just like the slug, it tells you where a link will send you to.

(Sander Datema) #10

My mistake, I thought that string would be the category name, but it’s the topic slug of course.

(Anton) #11

For anyone who does not understand English words for “topic” and “category”, it does not. WordPress is absolutely fine without any prefixes for categories and articles. I would say the question is vise-versa - why do we need these prefixes at all.

If that was configurable, I’d definitely switch the prefixes off.

(omfg) #12

WP is well known for its myriad of problems with URLs.
I’d rather have these c’s and t’s than have to set permlinks and struggle with occasional bugs (often caused by plugins that supposedly improve the great system that WP has).

(Wes Osborn) #13

When linking to topics, I frequently use the hostname.tld/t/NUMBER without the slug so the URL is more scannable / re-typeable (usually on handouts). The presence of the /t/ let’s me know immediately that I’ve linked to a topic. I also love that these links work even if the topic topic slug is changed in the future (the full links also continue to work if the title is changed too). But I also know that the topic slug in the URL is very important for SEO and other descriptive purposes.

Conversely if I am reviewing URLs and I see a /c/ listed, I know immediately that I’m going to be looking at a category. Even if english isn’t someone’s first language, I would think that the pattern would make itself clear overtime. I’m guessing that because the current URL structure is so clear from a human readable perspective that it also makes the system more reliable. If I we’re adding code to a project, I know I would appreciate not having the guesswork of determining if the ID just sent to me was a category or a topic.

So, I had the opposite reaction that you did once I groked the logic. I thought it was pretty brilliant, human friendly and reliable.

(Sam Saffron) #14

Just gonna through my 2 cents into this penny arcade, late on a Friday night.

We got to be doing something seriously right if “url structure” has somehow become a hot debate point.

Just putting this out there.

As to the change, no, I do not support this. There are a ton of painful edge cases.

  • Category names and topic names will not be allowed to overlap
  • If you name a topic “tags” we would not be able to route to it, same problem for a very large number of topics
  • This really does not add much, I am willing to bet that this is number 7000 in the list of things people really want from Discourse, would prefer investing complex engineering time on making our mobile theme better or a ton of other things.

(Anton) #15

Excellent, I didn’t know about this kind of links.

Unfortunately, not always true. Especially for non-it people. Example: none of my Ukrainian mods understand the links. So it just makes no sense for them, but adds noise to the links.

Sure, just expressed my interest in such a feature. I do understand it is nowhere near being a priority, and I did not plan to bring so much attention to the topic.

(Jeff Atwood) #16

It’s a very difficult change and would break a lot of stuff in Discourse.

There are reasons we made the choices we did.

(I am not saying all our choices are perfect, far from it, but we think hard about every detail of Discourse and every decision is a considered one.)

(Mittineague) #17

Moot comparison.
WordPress is PHP and Discourse is Ruby and Ember

Both Rails and Ember have Routing “magic” based on convention being followed.

IMHO messing with this for something so unimportant and unnecessary would not be a wise use of dev time.

(Nick Gray) #18

This would break a lot of stuff that us clever folk use to automate for home webpages and RSS scrapers for IRC bots, etc.

No thanks.