Pagination on Modules page list

I second this, but I realize the list format may be resource incentive. Therefore I suggest a daily cached version of http://drupal.org/project/Modules/name and its filters, perhaps with their own paths:

http://drupal.org/project/Modules/name/all
http://drupal.org/project/Modules/name/7.x
http://drupal.org/project/Modules/name/6.x
http://drupal.org/project/Modules/name/5.x
http://drupal.org/project/Modules/name/4.7.x

Thus the pages don't have to be generated for each logged in user/or role. The speed of the long list before suggest it wasn't cached at all.

I agree fully. I often open the full list, then search for a keyword using my browsers search function. For example if I need an SSL module, I may search for SSL, or HTTPS, or if I need an access module I will search for 'access'. I'm quite disappointed in this new change, as it makes searching for modules a much more difficult and time-consuming situation.

I don't think the pagination should be discarded altogether - obviously it's going to be preferable for some people, but the option of a non-paginated page is something I would REALLY like.

There is currently a problem with that page, it will be fixed later this week.

As a temporary measure, how about a 1-line help text at the top that points to the Alphabetical list of Projects, by core version from the handbook?

http://project.drupal.org/project/Modules/name

ok with me. But if you are poking at code already, maybe you can find out if the "long" mode of the page works again by reverting my hack. If it works, feel free to revert the hack. I'll look at the caching tomorrow or so.

I agree. I know I've already commented in this thread, but I just wanted to say it again - I'm REALLY disliking this pagination. I need all the modules and definitions on one page.

I reverted the hack on p.d.o and http://project.drupal.org/project/Modules/name is still timing out after 30 seconds. Not sure what killes is doing on the server side to try to deal with this. Seems like my work-around help text should probably go live in the meanwhile.

Ok, I committed my patch from #6 and deployed it on d.o and p.d.o. While I was at it, I increased the number of nodes displayed per page from 30 to 200. Now, instead of 95 pages to slog through, it's down to only 14, which is a bit more reasonable. Removing the pager entirely still times out on p.d.o and the other infra maintainers don't want to just "see what happens" on d.o itself.

Given the work-arounds now deployed, I don't consider this still "critical". It's a bummer, but this is all just a placeholder until the D6 upgrade, conversion to views, and starting to implement some of the functionality from the redesign, anyway.

the navigation of modules list its a pain :(

the search its not optimized to find titles... its really hard.

The pagination is a good idea, don't get me wrong. I just think it would be nice if there were ALSO the option of everything on one page.

If people don't stop repeating themselves without reading the rest of this issue, I'm going to mark this closed and lock comments.

A) WE KNOW THE CURRENT WORK-AROUND ISN'T IDEAL.

B) It's a WORK-AROUND for a FATAL ERROR on that page if you remove the pager.

The next person who posts in here without understanding those two facts gets a badge of shame.

Relax - there are two problems here:

1) I had no idea you were an admin - there is no reference to it anywhere in your post. Going back I can see where you were assigned to this, but as a first-time poster on this part of the forum (I've only been using drupal for about 4 months), how things work isn't particularly clear yet.
2) Going back and reading your comments in this thread, they weren't that clear to me (partly because I just thought you were another user). Whats a p.d.o? What's a d.o.? Is there a list of terminology somewhere? If you were a little more clear (to the layman) in your comments, I would have realized that you were on top of this. Until your last post, I thought that the only people commenting in here were other users.

Finally, you never mentioned until that last post that it was a workaround, that there was a fatal error, or that you guys thought it wasn't ideal. I'm very happy to see that this is just temporary, and that you are working to try to fix the problem. Saying so in plain English at the start of this thread would have held me back from pretty much all my comments. You are angry because we aren't understanding the two facts you just listed, but until you listed them, how were we supposed to understand that?

I understand your frustration, but you should realize that it's in part a result of the way you have handled this.

Granted, p.d.o and d.o are slang, sorry about that. I'll also grant that the description of the fatal error wasn't clear (#4 could have been slightly more verbose). However:

Given the work-arounds now deployed, I don't consider this still "critical". It's a bummer, but this is all just a placeholder until the D6 upgrade, conversion to views, and starting to implement some of the functionality from the redesign, anyway.

"Work-arounds now deployed..."

"It's a bummer..."

How was that not a clear description that this is a non-ideal workaround?

Anyway, it's all good. Sorry for not being clear earlier and slightly loosing my cool... But, hopefully my outburst will get other people in this thread to pay attention. ;)

No worries - I'm probably at the top end of the dense list - so if I get it now, then probably everyone else will as well.

a work around this would be with autopager, assuming you are using firefox
https://addons.mozilla.org/en-US/firefox/addon/4925
this simply loads all pages into one page and does so properly, if you feel hackerish you could probably roll up a perl script easily to do the same and concatenate all pages content together..

Thanks - I am using firefox, and I will be using that!

dww, I'm really sorry if I'm repeating, but you can pin that badge of shame on me (#15), because I still don't understand. Is there a plan in place to make the modules and theme lists available, with descriptions, on one page again? I think a lot has changed since last December. Where do we stand now?

After all these months I still get a little sick when I go to the modules page and can't hit Ctrl-F to start looking for what I need. I wonder if I would even stick it out if I were coming in new these days instead of a year ago when I could search as described in #3.

It's difficult to explain why this is so important, especially for novices. We used to be able to take a broad concept and skim the module list and quickly identify possible solutions. We didn't have to know what we were looking for before we started. We could start with a vague concept and quickly find more precise things to search for, and narrow down possible solutions. Now, we just have the search tool, which results in more long paginated lists...

Okay, say the list a big haystack, and you're looking for a bright red needle. Previously you could walk around and glance over the whole stack for some hint of red. Now, you have to go up close and first pick through this square foot, then the next, then the next, and so on. That's bad enough, but now what if the red needle were only a hint toward what you really needed to be searching for in the first place? Now you have to search through to page twelve before you figure out you should be looking for a teal colored needle.

That's when you start checking your pockets for a lighter.

(abaddonsun, your Firefox workaround sounded great, but the autopager addon didn't work out of the box for me. After an hour fiddling I still don't have it working. Do you have any pointers or can you direct me to some? If I had an afternoon to play with it I would probably get it going... )

It is unlikely that this page will be coming back. While I agree it is useful, it also needs a hell of a lot of memory to generate it. I am simply not willing to allow > 120 MB for this. So, unless a memory conserving method can be found to generate this page, I am inclined to mark this as "won't fix".

Is the problem that it takes too much memory for each single load no matter what else is going on? Or is it too much memory for such an important often-loaded page?

In other words, would it work if it were an option available when one needs it, instead of the default behavior for that page?

No, an option is no option in this case. The memory is required for each page load. The problem is that the page did a node_load for each node. These node loads are statically cached by Drupal and sometimes this causes problems. An option would be to load the node in such a way as to not statically cache it.

Would the same problem occur if search results all showed on one page? That would be almost as good.

I am not sure whether the apache solr search does a node_load for the results. It should not, I guess. If it does not, then yes, it would help.

I would be incredibly relieved if that could work.

I really miss the former functionality for the exact reasons that juroon said. It seems a backwards concept to me to remove functionality over time, especially when the removal of that functionality results in a significant loss of convenience. That page as an option instead of a default seems like an important page to have, obviously not just to me but to others as well.

We're "removing functionality" over time because the # of modules hosted on drupal.org has exploded over time. When that page was first written, there were about 80 modules. They fit on one page. Now there are close to 4000. I'm really tired of people posting in this issue who can't seem to understand this fact:

We will never list all 4000 (and growing) modules hosted on drupal.org and their descriptions on a single page ever again.

Use the faceted search. Help suggest concrete ways to make that better. "Just give me a giant page that causes the server to run out of memory trying to generate it so I can use my browser's 'search' feature" is never going to happen. Get it? ;)

Ok, different suggestion:

Split the modules up into four pages. The current system sucks.

Hakulicious, I can't bring myself to say "it sucks", although it's driving me crazy that my access to this list has changed.

The list and the tremendous effort that goes into maintaining and improving it, are surprising and beautiful things and don't suck at all. In fact, it's astounding that this stuff is available. Of course it's good to talk about what might be done about the cumbersome access, but let's not forget we're walking in here asking for something for free from people we don't even know. Clearly, they are smart enough to have thought of any obvious solutions, so let's acknowledge all that.

Sorry if I came on too strong with all that, but I needed to get it off my chest...

Four pages would be better than fourteen, but I think it would still be memory intensive, and frankly, I don't think I'd often get to the fourth page unless quite desperate. Still, it would be an improvement.

dww, what about the idea of possibly serving up module search result pages without chopping them up? Those pages could then be Ctrl-f searched. I don't mind running a search, I just get bogged down when it returns so many pages.

Is it true that those pages are not cached the same way the modules pages are cached?

"Sorry if I came on too strong with all that, but I needed to get it off my chest..."

No, not too strong at all. I agree with you that they do a very good job, and it's free for all of us. I am definitely appreciative of it.

But when I need a new module without knowing what module I need, I much prefer to be able to search through all the modules and descriptions, searching for specific key words. Right now that functionality either doesn't exist, or isn't apparent to me on where it is. If some other way of doing this search existed, it would definitely be nice.

"I much prefer to be able to search through all the modules and descriptions, searching for specific key words. Right now that functionality either doesn't exist, or isn't apparent to me on where it is."

How about the "Search modules" text field and the "Search" button on the right sidebar? 2nd block down from the top, definitely above the fold, etc.

http://drupal.org/project/modules

Whatever specific keywords you were going to enter in your browser search field, put it there and try it.

dww, that's the tool I have been asking about. It's some help, but it suffers from the same problem. If you put out a fairly broad search, because you don't yet know how to narrow it down, you're faced with too many pages to search through. It's extremely discouraging at that moment when you're feeling lost anyway.

I'd still like to know if it would it be possible for the results from that tool to show up on one page instead of being chopped up? Then one could use the browser search on that resulting page.

It's not clear to me yet if this would create the same kind of memory load since those pages may not be cached the same way as the modules pages are.

(That tool is much improved with relevancy and a quick and easy way to switch versions. However, relevancy is difficult to achieve if you yourself don't even know what you're looking for yet.)

Hakulicious, would that help for your purposes too?

Actually, that tool alone helps - I never noticed it before. Thanks for pointing it out dww.

But yes, I would prefer if the resulting page wasn't paginated. It would help.

It seems to come and go. It's easy to wander off on a different track where you're not on modules pages any more, and then you only have the main search field at the top. When that happens I have to go back to the main page.

totally agree with comments from #34, and when a broad search with the search box returns 9+ pages, it's disheartening to have to view 10, then wait for the next page to load, and the next page etc. i like to be able to search for a broad term, then narrow it down with ctrl+f and a search term. if that doesn't highlight anything of interest, i can quickly try another.

this is a big usability problem for me, as the search takes time, and waiting for the next page to load is slow. the alphabetical list doesn't really help as the module names doesn't always reflect what it does!

the ajax search on drupalmodules is nice, and is instantaneous, but i'd still prefer a list of relevant modules to go through.

just my 2c

Closing this. No longer relevant since moving to Solr.