searches not being restricted

I had the same problem.
I got it working by doing the following. (not sure if all of this is necessary)

1. Changed line 119 to

        $query = "INSERT INTO {search_block} (nid, enabled, dirty) VALUES ('%d', '1', '1')
          ON DUPLICATE KEY UPDATE enabled='1', dirty='1'";
      }
      else {
        $query = "INSERT INTO {search_block} (nid, enabled, dirty) VALUES ('%d', '0', '1')
          ON DUPLICATE KEY UPDATE enabled='0'";
      }

added "(nid, enabled, dirty)"

2. In phpMyAdmin I ran the following SQL

UPDATE search_block SET dirty=1 WHERE enabled=1

3. at '/admin/settings/search' I reindexed site

4. Then I ran cron.php

If you look in the table seach_dataset you will see all your nodes listed but the ones you don't want searched the data column will be blank.

I don't know whether this fixes the future operation of the module. If not I hope it sheds light on the problem.

BTW. Great module!!!!!
Kudos deviantintegral

Regards
Geoff

Not sure whether I needed to do all of the above as I have found that often it needs a couple of cron runs to reindex the site. I don't have that many nodes of the type that I change so I was a bit suprised. I am using this on a clients site so will continue to test it.

Again thanks for the excellent module.
Regards
Geoff

Glad you found a way to make it work. If you think it's a bug, please roll a patch and I'll see if I can replicate it.

This module is limited by the maximum number of nodes to be indexed as set in your search settings, so even with a small number of number of nodes it may take a few runs.

--Andrew

I am not sure that it is a bug. The SQL is missing '(nid, enabled, dirty)'

The patch attached heading info may not be correct but it will give you an idea.

Regards
Geoff

Thanks a lot! Fixed it for me as well.

Hmhm... somehow i have to repeat the step

"UPDATE search_block SET dirty=1 WHERE enabled=1"

To gett all done... I got the porter stemmer installed as well. This possible needs further investigations.

Is everyone affected by this on MySQL? What version? The patch in #6 should be a no-op: you should only need to specify columns if the order is different from the table order or you are omitting a column (such as an auto-increment id).

--Andrew

Yes, I am running on MySQL 5.0.54. Would be great if I can give any hand to make this module even better.

How many nodes do you have in your database? On a clean install, you can verify that 'dirty' is not being set properly? A watchdog log should be generated when a change is detected on a cron run. What are the values of the 'search_block_' and 'search_block_previous_' variables?

--Andrew

I am seeing the same problem. I use
Drupal 5.7
PHP 5.2.3
MySQL 5.0.24a
Restricted Search 5.x-1.0

I installed Restricted Search and edited about a dozen nodes to remove them from the search index. I cleared the search index. I upped cron to run hourly, and saw log entries like "search_block 05/21/2008 - 14:00 Dropping index for nid 1979" I just checked, and Search shows that 100% of the site has been indexed.

When I search on a term that would find the nodes that were dropped, the search shows a first page with no entries of the nodes that were removed, and shows that there are two pages of results. When I go to the next page of results, it now shows the nodes that were logged as dropped, and the number of pages of results is now three!

I have not applied any changes to the Restricted Search module.

Still having trouble replicating this. Here were the steps I used:

1. Bare Drupal 5.7 install
2. Added zen, devel, and restricted search. In this case I installed the -dev version, but it only has UI changes. You might want to give it a go just in case.
3. Used Devel's generator to create 50 nodes of type story and page.
4. Removed nodes 2, 3, and 4.

And everything worked as it should. I'm testing on Mysql 5.1.22-rc (apparently that's considered stable in FreeBSD's ports) and PHP 5.2.6, so they are different but not by much.

Can you check your search_dataset table? The SID's are equal to NID's, and should be empty for the restricted nodes. Perhaps another module is adding it's own terms.

--Andrew

I checked search_dataset table, and the nodes that I have marked as Restrict are in the table. I don't know what other modules might be adding terms.

Can I just delete these rows in the table, and then see if they stay deleted?

The rows should be in the table, but the words? field should be empty. You'll see other searchable nodes have all of the words seperated by spaces, and those removed from the index shouldn't have any words associated with them.

You're welcome to delete the rows, I think the worst case is that you'd have to reindex your site. It'd be a good idea to back up the DB first, just in case.

--Andrew

I checked the rows. The data field contains the words that I assume it should not. I had already deleted the rows before I read your reply, but I will try just deleting the words to see if that makes any difference, after the next indexing puts in new rows.

After I deleted the rows, the search no longer turned up the nodes that I wanted removed from the search. I saw no other harmful effects and the rows were not repopulated.

Do you have any other suggestions on how I can help diagnose why this is not working as designed?

It sounds like another module, or perhaps search.module itself is re-adding terms to the node. In search_cron() it doesn't allow me to control the order in which search modules are called; for this module to be effective, it needs to be last. Can you check your site for any modules which implement hook_update_index?

Thanks,
--Andrew

node_update_index
search_block_update_index
taxonomy_node_update_index

I just figured I'd chime on this since the module was working perfectly, then when I moved my site it stopped working.

I had built a site on my local xampp installation running MySQL 5.0.45 and PHP 5.2.3. Restricted Search was working perfectly and the proper nodes were not showing up in the search results. I then moved the site to the live server which is running MySQL 4.0.24_Debian and PHP 4.4.8. After the move the restricted nodes began appearing in search results and whenever I edit a node I get the following error message:

user warning: You have an error in your SQL syntax. Check the manual that corresponds to your MySQL server version for the right syntax to use near 'ON DUPLICATE KEY UPDATE enabled='0'' at line 2 query: INSERT INTO search_block (nid, enabled, dirty) VALUES ('180', '0', '1') ON DUPLICATE KEY UPDATE enabled='0' in /home/vhosts/example.com/httpdocs/includes/database.mysql.inc on line 172.

I don't know if this will help or not, but I just figured I'd share exactly what happened to me.

G

I may have found the problem; I think that it's due to re-indexing the site. If you remove a content type from the index, and then re-index the site, the type will be reindexed as well, and never removed. I think I have a solution, but it'd be great if others could confirm this behaviour before I code it up.

--Andrew

Subscribing.

Didn't have time to pursue this very far, but did find that re-indexing worked (i.e. correctly omitted blocked node types from search) when I ran the above mentioned query:
UPDATE search_block SET dirty=1 WHERE enabled=1

UPDATE search_block SET dirty=1 WHERE enabled=1 worked for me as well. I made drupal scrap the index and then I ran UPDATE search_block SET dirty=1 WHERE enabled=1 and then I ran the cron.

I've pushed out a new version version in the dev branches for both D5 and D6. It looks to be working for me when you reindex the site; can someone else test as well?

@ghumpley: My guess is that your version of mysql doesn't support the ON DUPLICATE clause. If you're still having problems with that error, please open a new issue.

Thanks,
--Andrew

I'm marking this as fixed as it WFM and there has been no feedback in the last month.

This is not part of 5.x-dev yet?

Yes, I link to the fixes I committed in #24.

--Andrew

I mean this one: http://drupal.org/node/169525 ?
(I dont use CVS)

Strange, everything looks good from my end, so I've filed a support request with the infrastructure team. Can you please try the CVS version? If you absolutely can't use CVS, you can browse the files online and copy / paste the code in.

Thanks,
--Andrew

Hi there,
Thanks for the effort so far. I have the same problem with drupal 5.10 and tried all the above examples with no success. Even the CVS addition did not help, although it seems to limit some content types, but with the next cron job they are there again.

Best Christian

I have to correct my message above. It works fine now and all content types are restricted. Thanks again!

Glad to hear it's working. I talked to dww, turns out that the tarball is fine, and it's just the project page showing the wrong date. It will be fixed when I next make a CVS commit.

--Andrew

Hi,

Ran across this problem and applied the latest dev build. However, it only seems to resolve this issue if your dataset is less than the items to index during cron setting. If you're dealing with large datasets (as I currently am), then the dirty bit gets reset after the first run as "search_block_update_index()" seems to be updating the dirty bit for all dirty nodes.

Any advice would be appreciated. Thanks.

Hi,

We have the same problem on our site as well. We've excluded a content type that has a couple thousand entries and it continues to show up regardless of what we do. We are on Drupal 5.

Hi,

Some additional information on our search issue - we have about 18000 total entries in our system and restricted search initially worked but after we made some additional entries and modifications to search we re-indexed the site and the restricted entries showed up again on the site. All re-indexes since then have not taken these items out of the search results.

Andrew, All the Dates in the CVS browser for the 6.x branch still say June -- are you sure it's the latest code?

Peace,
Ryan

The last log message is showing August 6th, which is when I committed the patch.

http://cvs.drupal.org/viewvc.py/drupal/contributions/modules/search_bloc...

I just committed a translation to the D6 version, so everything should be built within the next 12 hours to include that file. However, looking at the current .tar.gz, the ID string from the file is correct:

//$Id: search_block.module,v 1.1.4.5.2.2 2008/08/06 00:58:48 deviantintegral Exp $

Anyways, I should really tag a stable version, as it is currently it will be better than the 1.0 version, even if it's not perfect.

I'm having the same problem with the 6.x branch. Has there been any movement on this issue?

subscribing

I'm having this same problem -- content types show that they are restricted, but appear in search even after numerous re-indexing and cron jobs.

This is a hack for the large data set issue in Drupal 5 (i.e. data spans multiple cron job runs), so use with all of the obvious disclaimers:

1.) In the CMS at "admin/settings/search/restrict", do NOT restrict the content that you want restricted. This will prevent the module from un-restricting your restricted content during cron runs.

2.) Add Node API hook to your own custom node module for the content that you want restricted (i.e. my_forum.module) whenever the content is created or edited:

function my_forum_nodeapi(&$node, $op, $teaser = FALSE, $page = FALSE) {
  if ($node->type != 'forum') return; // only care about forums in this example
  switch ($op) {    
    case 'insert':
    case 'update':
      db_query("DELETE FROM {search_block} WHERE nid = %d", $node->nid);
      db_query("INSERT INTO {search_block} (nid, enabled, dirty) VALUES (%d,%d,%d)", $node->nid,1,1);
      break;
  }
}

Replace "forum" with whatever content type that you want to restrict. Add additional logic to case statement to handle cases where you only want to exclude certain content based on your business rules.

Again, this is hack that works with the D5 code without actually changing the search_block module code. I normally wouldn't post it, but it seems like a number of people are stuck.

No idea if it works in D6.

I had this problem today after installing the module - ticked certain content typesa to be restricted but they still showed in search results. I ran the query UPDATE search_block SET dirty=1 WHERE enabled=1 and ran cron which has fixed now.

I assume this fix not in the latest 5.x module download?

Many thanks..

How can I completely delete the search index table? From what I understand, this needs to be done before re-indexing with search restrictions in place -otherwise previously indexed data will still show up, unrestricted.

Thanks

G

I could help close out some of these bugs and work on the D6 version if you'd like another maintainer?

-John W

http://drupal.org/project/search_restrict
"Restrict by role who can search for each content type. Approach of this module is to re-write the search query, so that content is indexed and available as search results to users in role(s) that have permissions to view it, but not displayed to other roles."