Closed Bug 366620 Opened 18 years ago Closed 17 years ago

Remora URLs are inconsistent and contain featureless parts

Categories

(addons.mozilla.org Graveyard :: Public Pages, defect)

defect
Not set
minor

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: dao, Unassigned)

Details

(Keywords: regression)

For example, directories like addons/ (already part of the subdomain) and display/ (any site displays something) don't make any sense to the user. Compare addons.mozilla.org/firefox/398/ to addons.mozilla.org/addons/display/398. I'd say AMO 2 wins.

Take a look at the AMO 3 menu:

Recommended    => /addons/recommended/
Extensions     => /addons/browse/1
Themes         => /addons/browse/2
Search Engines => /addons/searchengines/
Plugins        => /plugins/

Of course, AMO doesn't treat Themes like Search Engines, but all technical quirks should happen on the server-side without being reflected in the URLs.
Here's the AMO 2 menu for comparison:

Extensions     => /firefox/extensions/
Themes         => /firefox/themes/
Search Engines => /firefox/search-engines/
Plugins        => /firefox/plugins/
Not a blocker, but thanks for the note.  We're gonna figure out the URL story a bit more as we go.
No longer blocks: 362526
Target Milestone: 3.0 → ---
Note that Remora is fully localized, so using urls like /firefox/extensions is no longer a simple issue, as the database doesn't have the "english" names for those things in the tables that refer to them, it has IDs that point to a translation table, which is why currently we are using ID numbers for them and intend to. A remora URL for /firefox/extensions would be /1/1.
Why shouldn't those IDs also have a fixed textual representation? Sure, "extensions" isn't optimal for all locales, but it's better than "1".
Most likely we will make static rewrites for applications(firefox, etc) and add-on types(extensions, themes) specifically, but not for anything else.(categories)
Sounds good.

For the record: I find browse/ as featureless as addons/ and display/ (and it's just another unlocalized part).
Now we have the comeback of the application name in the URL, so the issue got even worse :-(
How do you know the application when not through the URL?
Do you need to know the application everywhere? See bug 337198.
The URLs were improved a fair bit about 10 days ago, with things like /addon/1234 and /user/1234 instead of /addons/display/1234 or /users/info/1234 (though the latter still work).  We also have /browse/cat:4 as an alternative to /addons/browse/cat:4, in part so that we have a hope of refactoring the out-of-control AddonsController in the future (likewise with /browse/recommended).  If you see places that are linking to the longer forms, please let us know (comments in this bug are probably fine).  Concrete, actionable suggestions for other shrinkings are also welcome, though we are somewhat constrained by what our current version of Cake permits.

(I think we do need to know the application pretty much everywhere -- it helps us provide the compat information in the future without cluttering the page inredibly, as well as letting us do some of the things we're planning for improving non-browser installation, to say nothing of letting us not link to nonsensical search-engines or plugins for Tbird or Sunbird.  We should handle the wrong-app-for-this-add-on case more gracefully, for sure, but that's a bug and a separate discussion.  We also have different categories/tags for different apps, and we want to show the relevant ones only, etc.)

(Also, sniffing is perilous and makes correctness of caching _much_ harder to ensure, which is something that we already have enough trouble with.)

I'm going to mark this as FIXED, since I think we've removed a lot of the inconsistency and "featureless"ness with the recent work, and people should have specific examples to reopen.  I disagree that repetition of "addon" is bad, and would point to the craziness that is /firefox/1234/ vs /firefox/1234/author/ in v2 as an example of why we want to explicitly qualify what sorts of IDs we're manipulating.
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
Mike, I have yet to see a single place where it links to /addon/1234 - it is /addons/display/1234 everywhere. I will open a new bug on the inconsistent links.
Product: addons.mozilla.org → addons.mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.