The /download page from the drupal.org redesign prototype calls for a block with "Module categories" that includes a "More categories" link. We need a page to link to. ;)

Thinking through it, it doesn't seem particularly d.o-centric. I believe this can just be a feature provided by project_solr to make the project navigation more useful. Basic proposal:

- For each wing of the existing projects vocabulary that has sub-terms, project_solr provides a set of pages at /project/[project_type]/categories

- Each page has a set of solr-provided blocks, one for each category. The block title is the category name (and perhaps the facet count of total # of projects in that category), and top N projects in that category, and a "More" link that points off to /project/[project_type] with the appropriate category filter pre-selected.

- At the top of each page, there might be a UI akin to #428292: Download & Extend Landing Page: Filter by version for filtering by API compatibility, and possibly a drop-down to control the sort order for each category block.

One minor issue to figure out is how to make the CSS/markup for this page work right and make sense if you don't have bluecheese's grid CSS in place. Maybe we could provide some very light CSS in project_solr for this page to make sense on its own, and just let bluecheese override the CSS. We're almost certainly going to want a theme template for this page, and I guess bluecheese can just override that, too, to get the bluecheese-specific markup (esp classes).

CommentFileSizeAuthor
#13 878148-13.drupalorg.patch5.66 KBdww
#13 878148-13.project.patch14.44 KBdww
#11 878148-11.project.patch14.42 KBdww
#11 878148-11.project.interdiff.txt1.45 KBdww
#10 878148-10.drupalorg.patch5.66 KBdww
#10 878148-10.drupalorg.interdiff.txt1.62 KBdww
#10 878148-10.project.patch14.42 KBdww
#10 878148-10.project.interdiff.txt4.98 KBdww
#8 878148-8.drupalorg.patch5.24 KBdww
#8 878148-8.drupalorg.interdiff.txt2.77 KBdww
#8 878148-8.project.patch14.49 KBdww
#8 878148-8.project.interdiff.txt8.83 KBdww
#7 878148-7.drupalorg.patch2.66 KBdww
#7 878148-7.project.patch11.13 KBdww
#7 878148-7.project.interdiff.txt14.8 KBdww
#5 878148-5.drupalorg.patch4.79 KBdww
#5 878148-5.project.patch12.83 KBdww
#5 878148-5.project.interdiff.txt2.79 KBdww
#3 878148-3.project.patch11.87 KBdww
#2 878148-2.drupalorg.patch4.94 KBdww
#2 878148-2.project.patch9.26 KBdww

Comments

dww’s picture

dww
we/he/they
commented
Assigned: Unassigned » dww
Issue tags: +drupal.org redesign sprint 2

Based on a quick sanity check in IRC w/ csevb10, I'm working on this now... stay tuned.

dww’s picture

dww
we/he/they
commented
Status: Active » Needs work
StatusFileSize
new 878148-2.project.patch9.26 KB
new 878148-2.drupalorg.patch4.94 KB

Completely untested patch that's missing the core bit of magic. But, the skeleton is taking shape. Just wanted to post to checkpoint my work so far, and so csevb10 can start to see what I'm doing.

- We need to use drupalorg_block_render() in here, too. So, I moved/renamed that from drupalorg into project.module itself, since drupalorg depends on project, but not the other way around.

- We need the drupalorg_search_version_form in project_solr, too, so I moved/renamed that into project_solr, too.

- Added a %project_type menu argument loader function in project.module to support menu items like 'project/%project_type/categories'.

- Added the basic plumbing for per-category blocks in project_solr.

- Added the basic plumbing for a page callback for /project/%project_type/categories, a theme template and preprocess function, etc.

TODO:

A) Actually construct and execute the solr queries to populate these blocks. ;)

B) Write the theme template file itself for the mockup needed to generate this page.

dww’s picture

dww
we/he/they
commented
StatusFileSize
new 878148-3.project.patch11.87 KB

Still totally untested, but here's another version that heavily lifts from drupalorg_search_execute_base_query() to actually try to query solr for the right results. Still todo:

#1.B)

C) the // TODO about the "More" link

D) Consider if the giant cut+paste from drupalorg_search_execute_base_query() can be safely abstracted and shared.

csevb10’s picture

csevb10 commented

E) drupalorg_search_preprocess_drupalorg_download() has issues in that , we are retrieving the rendered form, and then attempting to make modifications to that form, so 

  $variables['version_form'] = drupal_get_form('project_solr_version_form', 'download');
  $version_alias = variable_get('project_solr_project_release_api_tids_alias', 'api_version');
  $variables['version_form'][$version_alias]['#title'] = t('Show only modules for Drupal version');

doesn't execute. We'll probably need to move the modification to a form_alter unless we want to get more tricky and/or provide addt'l params to the form.

F) drupal_strlower() (~line 412) doesn't exist. should be drupal_strtolower()

G) project_solr_version_form():

$query = apachesolr_current_query();

This line isn't returning a query object as expected, so everything downstream is failing. This looks like it's the case because we don't have any original query to fall back on since all of the rendering is happening in blocks. As a result, we can't pull a cached version since the blocks have yet to run at this point.

H) project_solr_category_page could probably use a brief comment that actual rendering is being passed off to the preprocess.

I) We should just make this point to our current function:

apachesolr_modify_query($query, $params, 'drupalorg_search_execute_base_query');

J) I always advocate for a wrapper around the call to theme('item_list') in case anyone wants to theme it differently. Calling directly to theme('item_list') basically just makes it more difficult to theme this item elegantly.

  return array(
      'subject' => check_plain($term->name),
      'content' => theme('item_list', $items),
    );

Ok. As we go, I'll probably note some more things, but this should at least provide some areas to work forward at the moment.

dww’s picture

dww
we/he/they
commented
StatusFileSize
new 878148-5.project.interdiff.txt2.79 KB
new 878148-5.project.patch12.83 KB
new 878148-5.drupalorg.patch4.79 KB

Thanks for the review! This patch fixes E, F, I and J from #4.

csevb10 is still debugging (G), since when we visually reviewed the code, it appears that it should actually be working.

(H) is related to (B). Honestly, as I look at this, I'm not convinced that a theme template makes much sense -- we need to programatically loop over all the categories (which we can't know ahead of time in the template) and dump them to the screen. I think a regular theme function would lend itself more readily to this. Then, the page callback can be doing the business logic that the preprocess is currently doing, which will be more obvious (making (H) irrelevant).

csevb10’s picture

csevb10 commented

K) [This may be deprecated based on changing the way we are handling things]

preg_match('/project_solr_category_(\d+)/', $delta)

should be

preg_match('/project_solr_category_block_(\d+)/', $delta)

L)

'project_solr_category_page' => array(
      'template' => 'project-solr-category-page',
      'variables' => array(

should be

'project_solr_category_page' => array(
      'template' => 'project-solr-category-page',
      'arguments' => array(
dww’s picture

dww
we/he/they
commented
StatusFileSize
new 878148-7.project.interdiff.txt14.8 KB
new 878148-7.project.patch11.13 KB
new 878148-7.drupalorg.patch2.66 KB

Decided to jettison the theme template approach for this page. This makes B, H, and L obsolete.

Also decided to stop trying to do this via the block system. It just adds complexity and doesn't really buy us anything. That makes K obsolete as well.

C, D and G are still TODO, along with probably this:

M) Currently, the theme function for this page just dumps everything into a single column. We should probably be more clever with the markup and CSS to render this as a multi-column "table".

dww’s picture

dww
we/he/they
commented
StatusFileSize
new 878148-8.project.interdiff.txt8.83 KB
new 878148-8.project.patch14.49 KB
new 878148-8.drupalorg.interdiff.txt2.77 KB
new 878148-8.drupalorg.patch5.24 KB

Based on feedback from csevb10...
G) is now working
This patch should fix C and D (although totally untested)

M is still TODO.

csevb10’s picture

csevb10 commented

So, first off: it works. :-)

N) project_solr_build_project_query() -- I feel like we should go ahead and make this function do everything through at least the query caching. I think we should move our $query_values call to after the apachesolr_current_query() and move the apachesolr_current_query() into the build_project_query().

O) I like this because it adds flexibility: (I'd probably make it 1 entry rather than have $filters = array() + $filters[], but it doesn't matter a lot)

$filters[] = array(
    'key' => 'im_vid_' . _project_get_vid(),
    'value' => $category_term->tid,
  );

but, I think that means we should remove this because it's now redundant and more limiting:

$query->add_filter('im_vid_' . _project_get_vid(), $project_type->tid);

P) Per usual, this should simply match the calling function:

$function_name($query, $params, 'project_solr_view_category_block');

Q) Since we're adding the filters based on the array, it might be worth adding them in the same fashion to facet.field, otherwise we're limited to the following 3 values for filtering purposes:

'facet.field' => array(
      'type',
      'im_vid_' . _project_get_vid(),
      'im_project_release_api_tids',
    ),

R) If you want to make the "more" urls utilize tid rather than im_vid_3, you can simply change the passed in filter in (O) above to be 'tid' rather than 'im_vid_3'. That, in conjunction with (Q) should make things work more as expected.

S) These use a non-existent $params array (since the params array is in the project_solr_build_project_query() -- a possible reason to either pass in $params or move everything through the search into project_solr_build_project_query()). This is the reason we get 10 results rather than 5.

// This hook allows modules to modify the query and params objects.
  apachesolr_modify_query($query, $params, 'project_solr_view_category_block');

  $solr = apachesolr_get_solr();
  $response = $solr->search($query->get_query_basic(), $params['start'], $params['rows'], $params);
dww’s picture

dww
we/he/they
commented
StatusFileSize
new 878148-10.project.interdiff.txt4.98 KB
new 878148-10.project.patch14.42 KB
new 878148-10.drupalorg.interdiff.txt1.62 KB
new 878148-10.drupalorg.patch5.66 KB

Upon further discussion in IRC, we decided that this helper should really be project_solr_run_project_query(), since we don't want to be passing around $params and all that. We have a solr response cache, so callers can get the response if they need it that way. I believe the attached patches address all of N through S. In terms of O, we decided it's the caller's responsibility -- the only implicit filter added is node type == 'project_project'. That way, project_solr can send in the category tid, while drupalorg_search can just use the blanket modules tid.

dww’s picture

dww
we/he/they
commented
Status: Needs work » Needs review
StatusFileSize
new 878148-11.project.interdiff.txt1.45 KB
new 878148-11.project.patch14.42 KB

Finally happy! csevb10 helped me see the stupid bug that was causing the version form to die from #10. See the interdiff for details. ;) Now deployed on the test site for folks to play with it and check it out:

http://solr.redesign.devdrupal.org/project/modules/categories

I'm going to punt the theme cleanup to separate issues (one in bluecheese for redesign launch, and a separate issue in project as a 6.x-1.0 wishlist). The actual plumbing is here. I gotta run now, but I'll file the new issues later tonight or first thing tomorrow.

drupalorg_search was unchanged, so 878148-10.drupalorg.patch is still the final patch for there.

dww’s picture

dww
we/he/they
commented

Bah, bluecheese already has hard-coded styles for the version form thanks to #881762: D&E Home - Search version form styling. We're going to have to reopen that once this lands to get the nice version form UI again.

Compare:

http://redesign.drupal.org/download

vs.

http://solr.redesign.devdrupal.org/download

dww’s picture

dww
we/he/they
commented
Status: Needs review » Fixed
StatusFileSize
new 878148-13.project.patch14.44 KB
new 878148-13.drupalorg.patch5.66 KB

Followup theme issues posted:
Bluecheese: #888156: Give the project/modules/categories page a multi-column layout
Project: #888144: Give the project/%project_type/categories page a multi-column layout

Latest patches no longer applied after recent commits, so I rerolled. Committed the attached patches to HEAD of both drupalorg and project. Merged the project changes into bzr and deployed live:

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

A work of art! ;) Thankfully, nothing links here...

Given that there are followup issues for the theme stuff, I'm going to call this fixed.

Status: Fixed » Closed (fixed)
Issue tags: -drupal.org redesign, -drupal.org redesign solr, -drupal.org redesign project, -drupal.org redesign sprint 2

Automatically closed -- issue fixed for 2 weeks with no activity.

Issue tags: +drupal.org redesign, +drupal.org redesign solr, +drupal.org redesign project, +drupal.org redesign sprint 2

Restoring issue tags, see #2125755: System messages removed all issue tags during D7 upgrade.