Question: What do people think about removing "taxonomy" from the "taxonomy/term/123" display so that it is consistent with "node/123" and "user/123"?

example.com/term/4 and example.com/term/4/edit look a lot more natural than example.com/taxonomy/term/4 (let alone example.com/admin/content/taxonomy/edit/term/1 which this patch will already replace).

Is it something of the system, that got into the urls, which shouldn't be the case? Any objections?

I took this from Add an Edit tab to term view pages.

Comments

mlncn’s picture

mlncn commented
Assigned: Unassigned » mlncn

+1 And I'll make the patch for this if approved in principle.

pancho’s picture

pancho
Location UTC+2 🇪🇺 EU
commented

+1: As I said in the other issue, I'm for it. The "taxonomy" part seems to be just unnecessary.
It used to be a good sign to find out that a website is made with Drupal, though. But now that everybody uses Pathauto not even that is the case anymore :)
Wait to see if there are any objections, but otherwise go forward.

kika’s picture

kika commented

What about old-style urls and linkrot? Do we need legacy.module again?

pancho’s picture

pancho
Location UTC+2 🇪🇺 EU
commented

That's a valid objection. As upgrade path I see several possibilities:

  • Add an admin setting that only for fresh installs defaults to 'term', but stays at 'taxonomy/term' for upgrades.
  • Hard-code a menu alias 'taxonomy/term/%' -> 'term/%', if this is possible without the 'path' module.
  • Create a legacy.module again. We might need more legacy options anyway.

Past decisions shouldn't hold us back in further improving the system.

Anonymous’s picture

Anonymous (not verified) commented

-1 I don't like the idea.

The autopath module can alias taxonomy/term/%tid to term/%tid if you wish this. Also unlike user and node the word term has multiple meanings and may not be related to taxonomy at all.

xano’s picture

xano
he/they
Primary language English
Location Southampton
commented

What about old-style urls and linkrot? Do we need legacy.module again?

Sites that are upgraded from D6 or lower to D7 may use Path to redirect the old-style /taxonomy/term/TID URLs to /term/TID. I don't think this will pose a major problem since not many sites will be upgraded at all and we mostly don't care about backwards compatibility anyway.

Also unlike user and node the word term has multiple meanings and may not be related to taxonomy at all.

You got a point, but what are the chances the word 'term' is actually used in a way that can conflict with /term/TID?

Anonymous’s picture

Anonymous (not verified) commented

You got a point, but what are the chances the word 'term' is actually used in a way that can conflict with /term/TID?

If someone created a module named term then /term is would be natural for the module. Both node and user are modules. Taxonomy is a module as well; but term is not a module which is another reason for disliking the idea.

EDITED ADDITION: Term is a byproduct of the taxonomy module and therefore /taxonomy/term *is* the URL that should be used.

xano’s picture

xano
he/they
Primary language English
Location Southampton
commented

There's no rule you can't use two distinct paths for a single module, but '/term' might be too generic for Taxonomy to use. I guess you convinced me :-)

catch’s picture

catch
he/him
Primary language English
commented

I think renaming to term would be fine.

I'd go for a commented out rewrite rule in .htaccess for the legacy URLs personally.

Anonymous’s picture

Anonymous (not verified) commented
Status: Active » Closed (won't fix)

There's no rule you can't use two distinct paths for a single module

Maybe we should help declare such a rule. The URL is as much a namespace issue as global variables.

but '/term' might be too generic for Taxonomy to use. I guess you convinced me :-)

Should we mark this a "won't fix", then?

mlncn’s picture

mlncn commented
Status: Closed (won't fix) » Postponed (maintainer needs more info)

No, let's not mark this won't fix yet. It's true that node and user also happen to map to module names, but term would be so much more intuitive.

It would not be difficult to keep both taxonomy/term/123 and term/123 working. It would be nice to only do that when needed (that is, when a site is upgraded) though.

catch’s picture

catch
he/him
Primary language English
commented
Status: Postponed (maintainer needs more info) » Active

Back to active. Earnie, one of us personally not liking an idea is different to it being won't fix, much as I might like that to be the case sometimes elsewhere. I'd say the taxonomy/term URLs are an accident of taxonomy module having two distinct objects supported, so it's an exception rather than the rule. What do you get when you go to /taxonomy (compared to /node or /user)? Nothing, that's what. Does the taxonomy module provide 'taxonomies' as tangible things you can see on the site? Not really. Different from node and user.

OK, so /term would currently give you nothing as well, but two pseudo folders just to preserve namespace that no-one has demonstrated has much of a chance of conflicting seems unnecessary. 301 redirects are a perfectly good method of dealing with the change for upgraded sites.

Anonymous’s picture

Anonymous (not verified) commented

Earnie, one of us personally not liking an idea is different to it being won't fix

Two of us had come to a consensus; I was testing the waters.

What do you get when you go to /taxonomy (compared to /node or /user)? Nothing, that's what.

Hmm.... I would consider it a bug. Should it not rather give a list of vocabulary to choose from? And then once the /taxonomy/vocabulary/%vid is chosen a list of terms from that vocabulary? Why do we keep the lists hidden and waiting for contrib modules? I know, I know this is OT; but catch started it. ;p

Does the taxonomy module provide 'taxonomies' as tangible things you can see on the site? Not really.

Really, I thought the list of terms for an article was a tangible thing. They a prominent with the displayed article and are clickable to get a list of articles based on the term. Sounds tangible to me.

There's no rule you can't use two distinct paths for a single module

Maybe we should help declare such a rule. The URL is as much a namespace issue as global variables.

You didn't comment on this. Shouldn't there be a rule for modules to use its module name as the first argument in the user URL (I don't mean for the administration URL's). It certainly has been the status quo for years. If this precedent makes it in to core it will give module creators the idea that they don't need to do this. Namespace will be destroyed by the modules trying to unencumber the user from a long URL. Core needs to lead the correct methods to create modules by using the rules it wishes to enforce on its own modules. This idea of changing /taxonomy/term/%tid to /term/%tid should not be done lightly; it does set a precedent for others to follow.

catch’s picture

catch
he/him
Primary language English
commented

I said "the taxonomy/term URLs are an accident of taxonomy module having two distinct objects supported, so it's an exception rather than the rule." - I think that stands in this case.

tracker also does /tracker and user/1/track - which makes much less sense than this change, if we're looking for precedents.

mlncn’s picture

mlncn commented

Earnie, I definitely see your point. In general the few modules that decide to create powerful paths should at least use their own namespace (not that this solves the problem of a module named "press" or something stepping on important namespace), but "term" as a longstanding Drupal keyword, so to speak, has special status also – node and user aren't special just because they have modules with matching names.

For the sake of simplicity and consistency, I very much want to see taxonomy/term shortened to term.

(And yes, going to /taxonomy should give you a listing of all vocabularies! But that's another issue.)

drewish’s picture

drewish commented

in addition to the needless link rot this would cause, i'm in the camp that each module should only take only one top level namespace and it should match their module's name. i think sticking things under user/%user is fine. so i'm opposed to changing taxonomy/term to term.

catch’s picture

catch
he/him
Primary language English
commented
Status: Active » Closed (won't fix)

Won't fixing this again. We have hook_term_path() and path aliases for this.