Now that the Drupal module is (presumably!) providing some concrete data on our installed base of modules and themes, we need to expand the sorting methods in project.module to include one drawing on these data. Then we'll be able to browse by what's actually being used. This will maybe also help encourage Drupal installs to enable the Drupal module.

CommentFileSizeAuthor
#1 project-browse-mostused.patch5.17 KBnedjo

Comments

nedjo’s picture

nedjo
he/him/his
Primary language English
commented
Status: Active » Needs review
StatusFileSize
new project-browse-mostused.patch5.17 KB

Here's an initial patch. We add a new browsing option like the existing ones. We model the behaviour on the recently-added taxonomy testing project_use_taxonomy(), i.e., this option is available if the drupal module is enabled and the 'client_system' table populated (meaning clients have connected and uploaded their module/theme data).

I've made a couple of small changes in the process:

1. Made the names of browsing options localizable (in the process corrected a recently-introduced bug in the menu handling, where array values instead of keys were being used for the browsing options)
2. Changed the browsing page title from e.g. 'Modules' to 'Browse Modules' (to avoid having 'browse by' repeated four times across the browsing tabs--it takes too much space).

TBD:

1. I don't know what this new browsing option should be called. As a placeholder I've called it "most used", but we need a better description than that. We're measuring the "size of the installed base", but that's hardly catchy ;) What we're up against is partly that this is an unfamiliar measure--people are used to seeing 'downloads', not real measures of usage.

2. How should we display data on numbers of installs in the listings? Showing absolute numbers would be potentially misleading--since this relies on voluntary enabling and configuration of drupal.module, we're capturing probably only a small portion of actual usage. Should we calculate a percentile?

3. We've talked about using data we're (maybe) collecting on number of nodes and number of users to help weigh the ranking, i.e., larger/more used sites weigh higher. This patch doesn't do that. Should it? If so, suggestions on how to do the weighing?

AjK’s picture

AjK commented

Tried this out. Like the browse feature but have these comments:-

  • The breadcrumb appears to break apart when viewing issues for a project created prior to the patch being applied.
  • the tab "by date" didn't appear to produce any list at all

best regards
--AjK

dww’s picture

dww
we/he/they
commented
Title: Create project sorting method using data from drupal.module » Create project sorting method using data from update.module
Version: x.y.z » 5.x-1.x-dev
Status: Needs review » Postponed

This is blocked on actually collecting some data via http://drupal.org/node/128827. However, as soon as that's done, we should re-roll this patch to use that, since it'll be more acurate data. Also, we should probably put the new sorting method into the proposed project_usage.module instead of doing it all inside of project's implementation of the hook.

drewish’s picture

drewish commented

i think this is the same as http://drupal.org/node/171269 which has a (likely broken) patch from my SoC work.

nedjo’s picture

nedjo
he/him/his
Primary language English
commented
Status: Postponed » Closed (fixed)

Long since done.

dww’s picture

dww
we/he/they
commented

Heh, not just done, it's now the default sort: #406728: Default sort on Modules / Themes pages ;)