Advanced search form doesn't scale with mega vocabularies.

I had a slightly different take on this and filed it here: http://drupal.org/node/42466 perhaps allowing administrators to decide which taxonomy terms to use would be the better way to go? Some of them might not even be relevant for searching.

I agree turning off advanced search should be in core, as well as excluding node types and vocabularies. I made a patch which will exclude node types and vocabularies. Do these have any chance at getting into 4.7? Pretty late in the game now, but they're usability, esp. if a huge vocab slows your search down, or for Robert's patch, if having an advanced search just is not appropriate for your site.

Ian

Sorry, here's the link to my patch http://drupal.org/node/42466 , which I should express does something different from Robert's patch, but I think both patches are very useful.

This patch is a great idea but i think node.module has changed to account for the forms api. The code from line 733 is not there anymore, rather it is around line 2100 in the new forms api format. I don't have the skills necessary to modify it to work but i'm sure someone can :)
Alex

I think non-free tagging vocabularies with 10K terms are rare enough to say that this should go to a contrib module. (I checked code, free tagging vocabs are skipped).

Thats not the only reason to turn off advanced search chx. Some people would prefer not to have it. I think it is a good patch

Id like to see this in. all that needs to be changed is the node.module patch to fall inline with form api

+1 for having the possibility to turn advanced search off. Last weekend, I did about the same as Robert on a site I'm working on. In my case, the reason was not the complexity of the site's taxonomy, but simply the internet skills/experience of the target group of the site. After some quick usability testing, it turned out that the advanced search box was confusing that particular group of users, so it was suggested to remove it.

So, after reading the other comments in this thread, I think there are several possible reasons why a site admin would want to turn advanced search off.

I think it may even be better to create a separate permission for this (allow advanced search) instead of one single on/off switch, to be able to restrict advanced search to certain roles.

Here is my version, based on latest cvs. Only problem with this patch is that in Robert's case, advanced search will always be available for user 1.

DriesK, you need to live up to a very famous name here -- and this patch proves that you do. Nicely done.

horray

I don't think we should commit this for 4.7. It introduces a new permission which by default defaults to off. But I leave the decision to Steven.

I thought about that as well. But on the other hand, the 'search content' permission itself is also off by default. So when someone enables the search module and goes to set that permission, he/she will see the 'use advanced search' permission right below. I don't think it's a major drawback.

This is a nice solution, for permissioning advanced search. But that seems like a strange solution for taxonomy terms taking too long to populate. Since development is opened up for CVS and we have a nice autocomplete form, maybe that can be put to use instead.

I committed this patch. Dealing with "mega vocabularies" is a separate issues. I updated the title to reflect this.

+1 for adding the ability to limit which vocabularies show up in the advanced search box.

We use a certain vocabulary to categorize content for internal purposes. We would rather not expose this vocabulary to the public.

Kevin

Finally got around to having a look at this one yesterday

Couldnt get the patch working directly with 4.7 (couldnt patch the file that is something about failing hunks) so ended up resorting back to the cvs files defined in the patch file .... works fine

now when u try and import these file into the current release candidate I'm getting a

user warning: Unknown column 'n.sid' in 'where clause' query: SELECT n.nid, n.vid, n.type, n.status, n.created, n.changed, n.comment, n.promote, n.moderate, n.sticky, r.timestamp AS revision_timestamp, r.title, r.body, r.teaser, r.log, r.format, u.uid, u.name, u.picture, u.data FROM node n INNER JOIN users u ON u.uid = n.uid INNER JOIN node_revisions r ON r.vid = n.vid WHERE n.type = 'node' AND n.sid = '23' AND n.score = '9.99971454137434' in /home/martin/public_html/site/moor47/includes/database.mysql.inc on line 120.

looks like im going to have to sit down and add each line by hand to trace the problem

any ideas
M

If the patch has been committed why don't we close this issue and then open a new issue or forum topic to discuss things that haven't been resolved yet.