Add search block for just project nodes
| Project: | Project |
| Version: | 5.x-1.x-dev |
| Component: | Projects |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed |
Per a recent comment on the devel list and a brief chat with killes in IRC, attached find a small drupal.org-specific module for consideration. All it does is add another block that duplicates the search block but is natively restricted to project nodes. The idea is to make finding a project easier, especially a project that already exists before you write a duplicate of it. (Although it of course has other value as well.) I'd think it a "disabled by default and user-enabled" block, like Contributor Links.
There's still an issue where the colon gets auto-escaped in the URL, but it still works properly and shows up correctly in the textfield. It's just in the location bar that it looks off. Suggestions on how to fix that, if we need to, are welcome.
(Rename from .txt to .module to get around file type limitations.)
| Attachment | Size |
|---|---|
| drupalorg.txt | 1.02 KB |
#1
And the info file.
#2
I guess this should be refiled to this module now. :-)
#3
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
#4
Against project module? That would introduce a search module dependency, wouldn't it?
I suppose ideally it would be a generic search-block-per-nodetype feature of the search module, but I'm not even going to try doing that to D6 at the moment. :-)
#5
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!#6
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 alsoor
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..
#7
check these:
http://sourceforge.net/search/
http://www.phpbb.com/community/search.php
#8
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.
#9
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.
#10
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?
#11
- 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...
#12
FYI: I configured the block to appear on http://drupal.org/project/project for testing, if anyone else wants to take a look.
#13
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?
#14
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
#15
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.
#16
Moving back home for posterity... ;)
#17
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.
#18
Yup, good catch, thanks. Committed to HEAD and DRUPAL-5.
#19
Automatically closed -- issue fixed for two weeks with no activity.