Add search block for just project nodes

There's nothing drupal.org-specific about this block (except what paths we want it enabled on, but that's just block configuration either way). I could certainly see other sites wanting this functionality, too. Please re-write this as a patch against project.module, then we'll get it on d.o.

Thanks!
-Derek

Actually, I think project_issue already depends on core search for the advanced search functionality. Although I never studied it closely, I'm pretty sure it's just re-using core's search indexes, etc. So, that should either explicitly list the dependency in the .info file, or move the "advanced search" to be conditionally defined. Here, you should be able to conditionally define this block via if (module_exists('search')), much like we add functionality if core's taxonomy.module is enabled. Thanks!

This is a much needed feature. +10 :)

The patch missing some key features. Should be something like this.

Search For: (textfield)
[                                                           ]

Search within: (radiobuttons)
(o) Project name
( ) Project name and description
( ) Project description only

Project type: (checkboxes)
[ ] Drupal project
[X] Module
[ ] Theme engine
[ ] Theme
[ ] Translation

Core compatibility: (dropdown)
Any (default)
7.x
6.x
5.x
4.7.x

and

[ ] Display projects without releases also

or

Limit results by last release date: (dropdown)
All results (default)
1 day
7 days
2 weeks
1 month
3 months
6 months
1 year

The module category should be considered also somehow. There are too many modules..

check these:
http://sourceforge.net/search/
http://www.phpbb.com/community/search.php

Here's a patch to project that is almost the same as from the original post but just reworked to be part of the project module.

@Pasqualle: Though I like your idea, I think that's a bit of scope creep for this issue. Also, with the pending port of project* to Drupal 6 (and, more importantly, to use Views 2), I think it's best to hold off on something like what you suggest until that point. It may be that once we get Views integration it'll be trivial to add all kinds of additional search features to such a block or page.

Evil, I can't get my local d.o test install profile to index content for search, even manually calling cron. :( But, otherwise, this looks fine, and appears to be doing what it's supposed to. Committed to HEAD. Thanks, folks, and sorry for the delay.

See also #289929: Provide Module/Theme Search Blocks which greggles just posted which does d.o-specific stuff like restricting to either modules or themes.

Grrr, I have no idea why but this doesn't seem to be working on d.o, even though it worked fine on a test site (other than my test site didn't index any search items). But, at least when you used the block, you got sent to the right place.

Once I put this on d.o, if you put anything in the search box and press submit, you just go to an empty http://drupal.org/search/node page with nothing selected or pre-filled. :( Any ideas?

- Maybe some block-level caching or something is breaking this?
- Perhaps someone else on the infra team has an idea, so I'm moving this there...

FYI: I configured the block to appear on http://drupal.org/project/project for testing, if anyone else wants to take a look.

Something (what?) is setting the action to search/node and this form doesn't exist there on d.o. It probably does on your test site though?

Interesting. For some reason, on my local test site, the $form doesn't have an '#action', but on d.o, I get this:

array (
  'project_search_block_form_project_project_keys' => 
  array (
    '#type' => 'textfield',
    '#size' => 15,
    '#default_value' => '',
    '#attributes' => 
    array (
      'title' => 'Enter the terms you wish to search for.',
    ),
  ),
  'submit' => 
  array (
    '#type' => 'submit',
    '#value' => 'Search',
  ),
  '#action' => '/search/node',
  '#base' => 'project_search_block_form',
  'node_type' => 
  array (
    '#type' => 'value',
    '#value' => 'project_project',
  ),
)

A little CVS archeology shows that d.o still hasn't been updated with the backport from #104662: Search blocks breaks if the block is not visible on the search page. (current revision on d.o is 1.209.2.5, latest in DRUPAL-5 is 1.209.2.6).

However, there are some local modifications to search.module for xapian stuff, so I'm hesitant to run the cvs update that will fix my current problem. The cvs update will do this:

@@ -1043,9 +1043,6 @@ function search_box($form_id) {
     '#attributes' => array('title' => t('Enter the terms you wish to search for.')),
   );
   $form['submit'] = array('#type' => 'submit', '#value' => t('Search'));
-  // Always go to the search page since the search form is not guaranteed to be
-  // on every page.
-  $form['#action'] = url('search/node');
   $form['#base'] = 'search_box_form';
 
   return $form;

@xapian aware people: can I run that update without breaking xapian? Seems like it should be safe, but I wanted to double check to be sure.

Thanks,
-Derek

I found killes in IRC, and he confirmed that the update should be safe, so I ran the update. As expected, everything is working fine now. Rolled it out on d.o at project* and search/node*. I also added a block setting for the help text to use, so we could add a little something site-specific to help people out (see attached patch if you care). Seems like this is now happy, so marking it fixed.

Moving back home for posterity... ;)

That last patch didn't add the new variable created to the list of variables to be deleted in hook_uninstall(). The attached patch does so.

Yup, good catch, thanks. Committed to HEAD and DRUPAL-5.