I have a business directory and I used CCK to create a custom content type to hold all of the various data fields I require. My problem is that I am using Trip Search and the only way to bring up nodes with the custom content type is for the user to have "administer nodes" rights. Obviously this is not acceptable for anonymous users to have this right, so I was wondering if there is a fix for this issue.

Thanks

Comments

joel_guesclin’s picture

I agree that it would be very nice to search in CCK - however I have not looked at all at how to do this and am not sure what the implications are. I have no idea how CCK content is distributed. For example, how would you get search to work on any text field in a CCK? Added to the fact that I depend on FULLTEXT searching and don't know how CCK content gets handled by the FULLTEXT indexes. So I will try to look at it, but I'm afraid the short answer is: "don't hold your breath".

joel_guesclin’s picture

Status: Active » Closed (won't fix)

I have tried this out briefly, using the latest version under 4.7. In fact, Trip_search will work on CCK types - including for anonymous users. However, it will only find keywords if they are in the Title of the node, since all other CCK content is in special fields about which Trip_search knows nothing.
If CCK goes on developing and there are more requests for this kind of thing, then I might look at it. This would be an enormous amount of work however. In the meantime, I would suggest looking at creating Views with custom searches built using exposed filters, and if necessary putting fulltext indexes on the fields that you search on.

fm’s picture

If CCK goes on developing and there are more requests for this kind of thing, then I might look at it.

fwiw, I gave this module a test drive but ultimately disabled it (and later removed it) because of its inability to work well with CCK content.

nedjo’s picture

The only relatively easy way to do this that I can think of would be to take a step closer to how core search handles indexing.

Core search renders the full node before indexing it. trip_search could take a similar approach:

  • Create a new table with maybe three fields: nid, title, content. Create content field with full text index.
  • Use a hook_nodeapi implementation that responds to node insert/update actions by generating the rendered the node and then saving it to this table. Alternately (probably better), crib from the indexing done in search.module to allow cron-based pulling of nodes into this new table.
  • Search based on this new table rather than node.

One complication is node access, but I imagine that passing the queries through db_rewrite_sql() should still work on this other table, providing the primary key is named 'nid'.