Closed Bug 343615 Opened 18 years ago Closed 18 years ago

Not Able To Browse Add-ons

Categories

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

defect
Not set
major

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 343578

People

(Reporter: r.a.beatz, Assigned: morgamic)

References

()

Details

Attachments

(1 file)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.4) Gecko/20060508 Firefox/1.5.0.4
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.4) Gecko/20060508 Firefox/1.5.0.4

When any of the categories are clicked to browse for add-ons, the page displays an error stating there are no results. The only way to view any add-ons is to search using a keyword, which is not very economical because users are not able to discover new add-ons, only search for ones they already know of.

Reproducible: Always

Steps to Reproduce:
1. Go to the Mozilla Add-ons page.
2. Click on any category, or the most recently updated or top extension (etc.) link.
3. The "No Results" page will display
4. Go back to the Add-ons page, and search for any random add-on. In example, use the word "save"
5. Results WILL display.

Actual Results:  
The site did not allow me to browse for any add-ons, but it did allow me to search.

Expected Results:  
When you click a category, it should bring you to a listing of all the add-ons in the category, allowing users to browse for more add-ons, instead of having to search for exactly the one they want. This doesn't allow users to come across new add-ons they have not been aware of.

Occurs in IE as well.
--> Update :: Public Pages
Component: www.mozilla.com → Public Pages
Product: Websites → Update
QA Contact: www-mozilla-com → web-ui
Version: unspecified → 2.0
Assignee: nobody → morgamic
Status: UNCONFIRMED → NEW
Ever confirmed: true
This looks messed up and the behavior is different from what I see in staging.  Jeremy -- do you know of any rewrites that might break this?
This is a possible fix, but logically it should be transparent -- search.php only differs by QUERY_STRING and the memcacheId set in init.php uses the same var, which the SCRIPT_NAME added in.

I still think it's most likely a problem with a top-level rewrite, or something strange going on with the cache entries or Smarty compiled templates.

*** This bug has been marked as a duplicate of 343578 ***
Status: NEW → RESOLVED
Closed: 18 years ago
OS: Windows XP → All
Hardware: PC → All
Resolution: --- → DUPLICATE
Product: addons.mozilla.org → addons.mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: