Project Solr: cleanup the API in preparation for the redesign

Everything looks good with the exception of 1 part:
project_sort_freetext. Previously, this was the start of the function: list($query, $response, $parent_term) = project_solr_response_cache();
and while the response and parent_term are unnecessary, $query gets passed to the submit handler. Since $query is never set in the new version, nothing gets set and the submit handler bombs out on trying to call methods of the query class.

Ok, this turned out to be a bigger issue than expected because on post, none of Solr actually gets executed. As a result, as far as the system is concerned, apachesolr_has_searched() is false, and therefore the block never gets drawn and the submit handler never gets executed. apachesolr_search_view is the culprit (commenting out the $_POST if statement fixes the submission, but the form submit redirect still doesn't behave as intended), but I still need to do more investigation to figure out what can be accomplished.

As promised, I'm attaching a patch update to this that fixes the original submission problem but still suffers from the problem just described. The following 2 lines are the only real addition to the patch:

  $response = apachesolr_static_response_cache();
  $query    = apachesolr_current_query();

related here wr.t. the POST check: http://drupal.org/node/735318

Note - it's bad to remove this or every search runs twice.

subscribing.

Changed two things.

1. The tid is in 'im_vid_'. _project_get_vid() .':' not 'tid:'
2. In form project_sort_freetext(), I don't think we need the query, so changed that and the submit handler.

There's another thing in doubt. I don't know which version of Apachesolr you are using, but in 1.0, $new_query->get_path(); returns something like "project/modules/xxx", not "project/modules?text=xxx".

Is this "needs work" for a known reason, or is this actually ready for review and testing?

OK, so I override get_path() in ProjectSolrQuery class so it doesn't keep the search query in the path (because we add the query to ?text=...). Now the blocks (the 4 in project_solr.module) work as expected. Please review.

re: #5 - the latest apachesolr code in CVS does away with the $_POST check. Will be in an official 6.x-1.1 release soon.

We're actively trying to upgrade apachesolr on d.o right now. Given the latest version of apachesolr, there's no need for our custom project_solr_order block anymore. So, this new patch removes that block entirely. It also undoes the change that was truncating the number of categories in the module categories facet block.

This is mostly working now on scratch.drupal.org. The one exception is that the default sort order is now lost, and back to using alphabetical. We want to default to usage stats descending. See #406728: Default sort on Modules / Themes pages for more.

There was some stray whitespace in project and project_solr that was causing some conflicts. Just committed fixes for those separately, so here's a reroll that applies to the branch.

1-line modification to change the default sorting method from title asc to usage desc.

Actually, #15 isn't needed at all. #14 is what we want. The problem was that the variable that sets the desired default sort for us is being defined in settings.php and the $conf values in settings.php are different between d.o and scratch.d.o. See #849634: Find a sane way to put (most of) settings.php into bzr for coordinated deployment across staging + live for more. ;)

Actually, looking more closely at this patch, there were some really crazy ternary operators inside foreach() in the previous code. I moved the isset() out of the foreach() to make the code more readable. This patch is now on scratch.d.o and seems to be working fine:

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

I'm planning to commit this and deploy live ASAP.

Committed to HEAD and deployed to scratch.d.o and d.o. Working fine:

http://drupal.org/project/modules

Yay! Onwards to the d.o redesign. ;)