Hello,
I have been finding that the options available to customize and alter the search performance are lacking. For instance, my site has node types that I do not want included in my search index. I would think it would be simple and useful to have in the search configuration the ability to exclude certain node types from indexing and searching.
In addition it seems the ability to customize things like what node fields get outputted in your search field without having to do some phptemplate work would also be useful. Also, the "no results found message" should be customizable as well.
I am willing to make a patch for these functions, but I am hoping you guys can provide feedback over what parts of what I mentioned would be consistent with drupal core functionality. (IE if it should not be in the core, but in a module or php template view override) Right now I see no way to override the no results found message about smurfs, and it would be reasonable to include that functionality as it is already done with the page not found.
Comments
I think you are right about
I think you are right about this - it is definitely a hard part of drupal to customise. Personally I think it should be handled in core, but this would be more likely if it were a feature request for drupal 6 as it is unlikely that it would make it into drupal 5.
You really do need access to the advanced search fields as an administrator, before the use sees anything. In fact for most of my sites a disable the advanced search by hacking into the core, but it could probably be done through a form alter hook.
There is an article on using a theme in php template to remove certain node types from the search results. Havent tried in in 5, but was very useful in 4.7.
With Drupal 5 and its brilliant integration of CCK I think that the ability to hide the page view of content types will become more and more important, as they are often being used in a way that does not warrant an entire page view.
But the way to go is clearly define what you want to be changed and then add it as a feature request to the search module.
What about
What about search_config.module? I think it's a good base to start as it does not stop astute users from placing the search criteria directly in the search text fields
Vito
One of the problems is
One of the problems is having some content types searchable at all. I use a number of content types that allow the site admin to add a row to a table etc. I need these to display on the site, but not create their own individual page. At the moment these content types are indexed on the site. I can theme them so they dont generate a link to the full node when they are displayed, but this does not stop them appearing in the search index. It would be great if the search module could restrict the content types that were indexed. In fact this may be more at the content level - perhaps there should be a way of removing the full display of a node (i think you can do it to a certain extent through CCK display settings, but it is not full control over the individual node. Sure, you can do it through theming but it is much less flexible.
Search config, from my usage
Search config, from my usage of it, just simply overrides the search/advanced form and changes the filtering. If you do a general search, the nodes that you do not want in the search will still appear in your results. The only way to not display them is overriding the search theming function in PHP template. This is a hack that is not even a very good one. It does the job, but suppose I want to not show image nodes that all have a url /images/foo, If I do a search for "image", a lot of empty pages will come up because the pagination is already done before you hide certain results. And from an efficiency standpoint, it is terrible because these unwanted nodes are being indexed and queried and then hidden which is completely unnecessary if they were never indexed to begin with. If the core node_search hook was changed, you could easily not index certain nodes with a few lines of code and no overhead. I am going to place a feature request for 6, and make a patch. We will see how it goes!
excellent idea - exactly the
excellent idea - exactly the problem i was trying to describe!