Optional Exclusion of Taxonomy Vocabulary from Advanced Search

Attached are two patches that apply to node and search, for RC2, which will give you options on admin/settings/search to select which node types and which vocabularies to exclude from searches.

Ian

I made a mistake - this is for the current HEAD, not for RC2

The category module only shows select boxes for containers (i.e. vocabs) on the advanced search page, if those containers are associated to one or more node types. So if, for example, you have a 'glossary' container that's only used by the glossary module, and that doesn't have any of the 'type' checkboxes ticked on its editing page, then that container doesn't show up on the advanced search page.

Perhaps the core taxonomy module should implement this feature as well? It might be an easier thing to get into core than having users explicitly mark vocabularies as being on the 'advanced search' page, as that involves complicating the UI further, whereas this approach involves no UI change.

Hi jaza,
I see what you are saying. Are there any cases where this would be a disadvantage?

I applied this patch on our dev server, tested it and pushed it to our production servers. Worked very well, and was able to get about 2,500 keyword term pages and two internal node-types out of view. Thanks for writing it.

Might wrap the new fields in search settings around a fieldset just for consistency with the other items.

-Greg

I tried to apply this patch to the current 4.7 release and it returned errors.

Does it need to be updated or is there now another way?

TIA,

Kevin

I applied this patch to a 4.7 release. Make sure to change the variable names in the existing form elements, that tripped me up for a moment.

---

One afterthought, excluding a node type from showing up in the advanced search will not exclude it from the search results. For instance, I have a node type called summaries used for reporting - only certain roles can see these nodes, but they show up in all search results (if I publish them). Would prefer to set "include in search" from the node or vocabulary side. Similar to what Jaza is saying above I think.

@gbear: can you elaborate, not quite sure what you're saying there.

Wrote the stuff below, and then realized what we are really doing is using quick&dirty modules to do realtime internal reports - without tacking on an outside reporting tool. But I have a hard time getting these internal reports to NOT showup in search results to customers or get picked up in Google. Writing a module to do a custom report is certainly easier/faster/more integrated than using some app like Crystal to accomplish the same thing.

---

Here's an ideal scenario for us -- & I think this would be relevant to Drupal users who have created custom node types/modules.

In the content types administration page, a checkbox is added that says "what roles should be able to search for this node". (Checked to all roles by default of course). Unchecking a role causes that particular node type to be completely disabled from both search results and appearing in the advanced search view if ther person doesn't have access permission.

Something similar could be done with the Vocabulary admin, where you could choose whether or not the entire vocab should be inculded in search. That is how I read Jaza's post above.

I saw in Dries post today http://drupal.org/node/66722 on updates in the works that you are doing something that sounds similar with Blocks - adding roles to the visiblity of blocks. Same concept could be applied to node visibility in search.

As a more granular step - could append a new fieldset to every node where you get to choose "what role should see this page." I often create pages (for instance with content reports, or canned queries) for our writers to use. I just leave them as unpublished and send people to the node to view. The node type (for instance Page) is available for all users, but I have specific pages that are for a subset of roles use.

(skipping ahead a bit...)
One of the most interesting models for access mgmt I have seen in awhile is in SalesForce.com - you setup your information org chart, and that controls page visibility - basically just a hierarchy applied to the access roles. You set it up once though, and then don't have to worry (as much) about granular permissions at the record level. A user can only see what is at their level or below in the tree.

Thanks for asking, happy to test-drive most anything in our dev environment.
-Greg

so can we exclude certain node types from appearing in both search form and results, does it apply also for taxonomy ?

about the patch that someone posted above
did it work and how to apply it

Why would you want to exclude certain terms from being shown? Because some modules are abusing the node or taxonomy system to do thing they shouldn't be doing? :)

If you have legit reasons to restrict terms from being shown, you can use one of the available access modules.

There's the option of doing this sort of filtering in a contrib module through form_alter.

That's a big performance hit, though. This feature would be useful when you're dealing with dozens or hundreds of taxonomy terms. Using form_alter, you'd first add every taxonomy term in the system, then strip them right back out again. You'd also need to know exactly what it is you're trying to strip. If it's admin configurable, then that's a setting to check, too.

Ideally, a module should be able to just say up front that it's taxonomies shouldn't be searchable and leave it at that.

That's a big performance hit, though.

True. So a better way would be through hook_db_rewrite_sql(). Something like (the $query is that issued by taxonomy_get_vocabularies(), called indirectly by the search code):

/**
 * Implementation of hook_db_rewrite_sql
 */
function example_db_rewrite_sql($query, $primary_table, $primary_field) {
  if ((arg(0) == 'search') && (arg(1) == 'node') && ($primary_table == 'v') && ($primary_field == 'vid') && ($query == 'SELECT v.*, n.type FROM {vocabulary} v LEFT JOIN {vocabulary_node_types} n ON v.vid = n.vid ORDER BY v.weight, v.name') && ($exclude = variable_get('example_exclude_vocabularies', 0)) {
    $return['where'] = ' AND v.vid NOT IN (' . implode(',', $exclude)';
    return $return;
  }
}

That hook_db_rewrite_sql() example might be better performance-wise, but it would be a major code ugliness hit. :-p

An if { /*...*/ } statement with 6 checks? And a direct text check of the query itself? Ugggghhhhh. Surely there's a better way.

Well, I'm only tossing out a rough draft to save someone who indeed wants a solution a bit of time. Some of those ifs obviously could be omitted, likely, including the query. I would test for what other taxonomy query calls occur at /search/node and remove ifs accordingly.

So, the taxonomy part of this feature, which applies to a relatively small portion of sites, probably can be achieved (more cleanly, and with fewer lines of code) in a contrib module.

I applied this patch and it does exclude vocabs and/or node types from the search page, but NOT the results.

Why would you want to exclude certain terms from being shown? Because some modules are abusing the node or taxonomy system to do thing they shouldn't be doing? :)

If you have legit reasons to restrict terms from being shown, you can use one of the available access modules.

Well, if you are using OG (as in my situation), there are no other forms of access control available - unless that's changed recently. Also, I am using OG_forums which creates terms for each forum under each group. Who wants to see all that in the vocabularies box. Users would do better to search by the general topics or freetagging vocabs I set up and check off "forum" node type.

I think it's a "KISS for naive users" issue.

Is there really much overhead in implementing this?

I am also addressing the issue of displaying all terms created by of_forum whenever a vocabulary list box is displayed.
http://drupal.org/node/72374

Use cases like?

I'm not really fond of the proposed patch, although it gets the job done. It sorta hacks the functionality onto the taxonomy module using a variable. The better solution might be to add a bit-flag to each term (in the term_data table). Unfortunately, that wouldn't work for the content types.

The patch shouldn't use tabs though.

Another use case: freetagging. add 10.000+ tags.
-bang-crash-browser-booboo-. A selectlist containing 10.000 entries will bring down almost every decent browser. And it costs you dear bandwith. Worst: it will make the search page load forever, for no apparent reason. It clutters the interface, because a list with 10.000+ entries is useless.

Why would you want to exclude certain terms from being shown? Because some modules are abusing the node or taxonomy system to do thing they shouldn't be doing? :)

. Is that not up to the person who is running a website to decide? Why would my software limit my options, for no apparent reason then a thing 'thing they shouldn't be doing' according to Dries.

The performance concern here is completely valid, and long select lists are nasty in general.

How about changing the taxonomy filter selection to an autocomplete widget when there's more than x terms (this would also be re-useable for parents/related terms in taxonomy admin I guess). For the "scalable menu parent choosers" issue in D6 we added a variable check before the form declaration so it'd be easy to swap out the form element without the loading/unloading nonsense, a similar approach got in for the taxonomy parent form but it'd be nice not to have to do that.

Put simply: With the introduction of freetagging, this becomes an important issue.

Like the previous commenters I really had to get rid of a freetagging taxonomy from advanced search because it made that feature unusable.

While I'd like to be able to catch this before it goes to the user's browser I did not want to hack core or do any other questionable methods like rewriting sql queries. So here is the suboptimal but trivial solution of removing an optgroup with Javascript:

$(document).ready(function() {
$("optgroup[@label='YourLargeTaxonomy']").remove();
});

Unfortunately, it is now too late for Drupal 7 feature requests.

Actually, this is a duplicate of #82330: Add ability to enable/disable individual vocabularies in advanced search.