To reproduce:

1) Browse modules by category, picking a category with a lot of modules (I found this in "community")
2) Set the filter to "all"
3) Go to page 2 via the link at the bottoom

The filter resets to 4.7. If there aren't two pages of 4.7 modules, you end up back at page 1. Changing the filter to "all" again does correctly show the 2nd page, though, so this isn't a critical problem.

Michelle

Comments

RobRoy’s picture

This is probably a duplicate of http://drupal.org/node/83727 but since the scenario is a little different, I'll leave it open for confirmation.

dww’s picture

no, these are actually completely unrelated bugs, and should remain separate issues.
in my work for the new releases sytem, trying to get the module browsing pages to work, i ran into this bug again. however, i now understand the code a lot better. ;) so, hopefully i'll be able to resolve this with a little extra help from nedjo as soon as the new release system is live.

dww’s picture

Assigned: Unassigned » dww
Status: Active » Needs review
StatusFileSize
new2.39 KB

in doing the D5 port, inspired by the attempt AjK made at fixing this problem, i got it working correctly. ;) here's a patch for 4.7.x-1.x.

dww’s picture

Version: 4.7.x-1.x-dev » 4.7.x-2.x-dev
StatusFileSize
new2.64 KB

and here's the one for 4.7.x-2.*. this is actually more important to fix (since it's what's running on d.o) so i'm moving the version of this issue to match.

the version of this fix for HEAD is already included in my latest patch in http://drupal.org/node/99759.

dww’s picture

FYI: this patch is now installed on scratch.drupal.org if you want to test it out there. e.g.:
- http://scratch.drupal.org/project/Modules
- change the Filter by Drupal Core compatibility value and hit 'go'
- switch tabs or click on other categories, etc.

dww’s picture

oh, this patch isn't on s.d.o anymore, since that's now running the latest HEAD code: http://drupal.org/node/105004

deanypop’s picture

Just curious, but given the relative importance of this feature ALWAYS WORKING at the main drupal.org site, any chance the patch could be applied to the production site, assuming the 5.0 version isn't imminent (like, today)?

;) Just really annoying, since we can't organize by date and* expand the page to fit all the projects for, say, drupal 5.0.

dww’s picture

Priority: Minor » Normal
Status: Needs review » Fixed

yeah, i know how you feel. ;) which is why it can be so annoying when people don't review and test my patches to fix stuff like this for days/weeks/months on end. :(

anyway, i just committed a slightly modified version of the previous patch (which avoids an unnecessary redirect) to the DRUPAL-4-7--2 branch, and installed it on d.o. all working nicely now.

enjoy,
-derek

dww’s picture

Version: 4.7.x-2.x-dev » 5.x-1.x-dev
Status: Fixed » Active

apparently, this doesn't work if you're anonymous, only once you log in. :(

dww’s picture

Priority: Normal » Critical
Status: Active » Needs review
StatusFileSize
new2.94 KB

how about this:

- for anonymous users, the selector is disabled (set to the default value) and it prints "You must login or register to modify the filter." (with links).
- we make the default filter [all] on d.o.

should hold us over until we implement http://drupal.org/node/107813 (assuming we're ready for the link rot that might entail).

dww’s picture

dww’s picture

better patch:
- uses l() not url()
- removes a line of dead code
- reorganizes to be more clear

heine’s picture

Status: Needs review » Reviewed & tested by the community
dww’s picture

Status: Reviewed & tested by the community » Fixed

committed to HEAD (back-ported to DRUPAL-4-7--2) and installed on d.o.
YAY ... fixed at last!

Anonymous’s picture

Status: Fixed » Closed (fixed)