Make the alphabetical list of projects not suck so much

Actually, it's http://drupal.org/node/206666 . I also gave this issue a more descriptive title.

That page was created a while back when I asked for it on IRC. I wanted an easy way to find a module by name because the main module page was so huge and hard to search through. I think it might have been hunmonk that made it for me but not 100% sure. At any rate, it's a query that was put together rather quickly and not meant to be fancy.

I'm not sure the page is as useful anymore now that we have a proper search. I haven't used it in some time. With 4K modules and growing, even a list of titles with no descriptions is huge.

Michelle

Hehe, this page is our appeasement for people who miss the old "all in one" module listing under /project/modules. not sure we should remove it.

And to answer the original question: no this is not a view. The text can be edited normally if there is an agreement on how to change it. Not sure abotu three columns, would be too wide for my screen.

No, it's not currently a view, but it should be. So, if we want to change it, step 0 should be converting it to a view.

Step 1 should be adding an exposed filter for the core version (with "- Any -" as the default, but supporting 7.x, 6.x, 5.x, etc). There's no reason for 3 column layout. People using this page are just searching for modules by name. I'd guess that the vast majority of the time, they know what version of core they're trying to build a site with, and want to restrict their search by that, anyway.

Step 2 should be giving it a sane path and adding a redirect from http://drupal.org/node/206666

@Gerhard: Ah, I didn't realize anyone but me actually used the page and I stopped using it once the search stopped sucking. :) The reason I asked for it to begin with was that I often knew the module name but not the path and it was easier to do a quick find on that page than on the monster module list. Now I just search for the name and limit to projects and I got it. :)

dww's plan sounds nice. Would make the page useful for browsing.

Michelle

@bekasu: Start from here, you'll have a lot more luck:

http://drupal.org/project/drupalorg_testing

That said, there are some limitations in the project views support (project_issue views support is great, but not so for projects and releases (yet)):

#76726: Refactor project module to use Views [meta issue]
#357925: Provide default project browsing views that don't depend on project_release
...

So, sadly, you're not really going to be able to click this together with proper version filters just yet. :( Might make sense to mark this issue postponed in favor of finishing up the known work that needs to be done at #76726...

Yeah, this is just blocked (postponed) not waiting for more information from anyone.

Also, it's not an official release of views you need, but more work on project + project_release's own views integration...

Cheers,
-Derek

Why not make the alphabetical list of projects more like FAQ, click on a title and summary detail is shown below the content.

@browlands: Because that either requires AJAX (more complicated) or it requires putting all that data in the page in hidden divs, and then the page is way too huge to generate and download, probably running out of RAM, which is why this page exists in the first place.

#12 OK, how about an A-Z list as currently shown including < letter > and < back to top > where the letter anchor is the beginning of projects beginning with a certain letter. Also include a small description perhaps the one from the .module file, cache the description so that it doesn't need to be retrieved from the .module file. Show as a view with the branch version (5,6,7) as an exposed filter, or otherwise as a facet available for searching. More or less a rehash of the update module.

Perhaps the page could be replaced with tabbed pages, so we have a list of modules per core version, rather like the core version tabs in the drupal API docs.

The default tab would be modules for the current core version.

#5 has the basics of this plan.

https://infrastructure.drupal.org/drupal.org-style-guide/prototype/modul... has an Index block that is needed too, replacing the drupal_set_message().

Initial version of a view for this. Provides a page display at /project/%project_type/index and a block display. I'll put this on scratch for people to play with.

Here it is on scratch. The view I attached doesn't include the sort, but I added that now.

http://scratch.drupal.org/project/modules/index
http://scratch.drupal.org/project/themes/index

I guess I should still add the core version filter...

But, otherwise, how's this looking?

http://scratch.drupal.org/node/206666 (care of #780322: deploy path_redirect on drupal.org which I put on scratch.d.o for final testing)
http://scratch.drupal.org/project/themes/index
...

This is really slick. hook_views_default_views_alter() kicks ass. ;) I have the default view in project.module that just includes the titles of all projects, no version filter (basically patch #18 + the title sort). Then, in project_release.module, I alter this default view to inject the relationship and filter we need to get the version selector working. Then, in drupalorg.module, I alter it yet again to change the labels on the filter to be d.o-specific ("Drupal core" instead of "API compatibility"). ;) Whoot!

I also have patches (for both DRUPAL-6--1 and HEAD) of drupalorg module to rip out the crappy custom code that used to populate this page and the weird hook_help() hack to link to it.

The only final problem in here is the block. Currently, there's no good way via the core block UI to define arguments to the block. So, we can't have the block just appear how we want it to (e.g. on http://scratch.drupal.org/project/themes there'd be a "Themes index" block with the first 5 entries and a link to "Full index"). I only know of two ways to make this work:

A) Add a custom default argument plugin to project that tries to figure out the active project type from the URL

B) Write a custom block that does the logic we want and then embed the view

Neither is particularly great, although (A) is probably cleaner and better long term (and might be useful for other project* views down the road). I'm going to give that a quick spin to see if it's going to work.

(silly bot) ;)

Okay, this default argument plugin wasn't as bad as I thought, and works quite well:

http://scratch.drupal.org/project/modules

However, now that I see it in action like that, I don't believe we want this block to even display on this page. Instead, I added a link to the index in the taxonomy term description for modules so it's at the top of that page (and at http://scratch.drupal.org/project).

For the http://redesign.drupal.org/download page we're going to need to embed the block directly in the theme preprocess anyway, so at that point, we can just hard-code the 'modules' argument.

Changing the view to use an ol for the display type gives us a live counter of modules or themes on d.o:

http://scratch.drupal.org/project/modules/index
http://scratch.drupal.org/project/themes/index

I kinda like it. ;)

Any final objections or should I roll this out (I won't turn on the block on d.o itself, I'd just update the module description to point there).

In IRC davereid pointed out we could also filter out abandoned modules. However, there are currently two independent ways that we do this -- there's the "Maintenance status" vocab, and the "Abandoned Projects" user. :( Until we converge on a single system for this (presumably the vocab) I'm a bit reluctant to add anything to this view to filter by it...

code looks good, tested it on scratch and works well.

the only thing i'd add is that we might want a link to the theme index under the theme description, just like we have for modules.

http://drupal.org/project
http://drupal.org/node/206666
http://drupal.org/project/modules
http://drupal.org/project/modules/index
http://drupal.org/project/themes
http://drupal.org/project/themes/index

Probably goes without saying, but just to be clear: committed #22 to HEAD of Project, imported into bzr, merged into d.o branch, merged d.o branch into redesign branch. Committed both drupalorg patches from #20 into their respective branches, imported DRUPAL-6--1 into bzr, merged into d.o branch, and deployed all of the above on d.o. r.d.o will auto-deploy itself...

uh oh, looks like this update to drupalorg module clobbered the redesign site: Fatal error: Cannot redeclare drupalorg_views_default_views_alter() (previously declared in /var/www/redesign.drupal.org/htdocs/sites/all/modules/drupalorg/drupalorg/drupalorg.module:531) in /var/www/redesign.drupal.org/htdocs/sites/all/modules/drupalorg/drupalorg/drupalorg.module on line 733

and indeed, on inspecting the code it appears that you added drupalorg_views_default_views_alter() when an implementation of it already existed... ;)

Whoops. ;) Thanks for letting me know. Committed a fix to HEAD. This should be merged and deployed on r.d.o automatically in a few minutes... I'll set this to fixed once I can confirm the fix.

http://redesign.drupal.org is back up. hudson is in the middle of the giant d.o -> r.d.o sync job, so the hudson job to merge from drupalorg HEAD into bzr and deploy was queued up for a while. the DB is in a bit of an inconsistent state with the site sync still running, but the fatal error is now gone so I'm setting this back to fixed.

Yep, I kicked off another round of deployment, and it should be working.