Maybe i understand this incorrectly - but i think adding content to a node field (not just title or body) will have that content indexed into the search index table.

In other words (and i know cuz i just tried). If i add a new field to an existing node type, and then enter a word in that field for an existing node, run cron and then search for that word - my node is found (BTW - my search is a view which uses fast index search - but still based off search index tables).

If i know edit that node again and add a nodereference to that node (and run cron) - and search on a word from the title of that node reference - my node is not found.

E.g.

node type: news
field in news is noderef to type artist

a search on artist's name only returns news item if their name is included in text in the node somewhere; but if it is just in the nodref, it doesn't.

Peter Lindstrom
LiquidCMS - Content Management Solution Experts

Comments

Amalanthe’s picture

Amalanthe commented

Yes, I have the same problem. If a cck field is a node reference, it is not in search results.

jtjones23’s picture

jtjones23 commented

same here

smitty’s picture

smitty commented

Well, I'm afraid that this is not only limited to the nodereference fields. None of my cck fields is in search results.

Others seem to have experienced the same:
http://drupal.org/node/199599
http://drupal.org/node/69981

smitty’s picture

smitty commented

Sorry for disturbing here.

I found out, what my really problem was: I had put the cck-information into a block and so it was not indexed any more, because, the search module indexes everything what is displayed on the page but not, what is displayed in the block.

To get the information back into the index, I just had to include the block-output into the case ‘update index’ in the hook nodeapi of the module I’ve written to manage the cck block.

I can’t tell you anything about the nodereference fields because I don’t use them.

liquidcms’s picture

liquidcms commented
Version: 5.x-1.6 » 6.x-2.x-dev

seems like this is still the case in D6 - am i doing something wrong.. why are noderef fields not included in search indexing?

markus_petrux’s picture

markus_petrux commented
Category: bug » support
Status: Active » Fixed

See "Display fields" screen, secondary tab "Search", column "Search index", find your noderef. field and select a formatter of your choice. The rendered output of the field formatter should be used by the indexer process, as it should be with any other kind of field.

liquidcms’s picture

liquidcms commented

Yup, it does work.. i had 1 added level of related info that i hadn't realized. which is too bad that THAT doesn't work.. and surprised no module for it.. i really need to do one... what i am referring to is recursive search indexing for noderef fields.

so what i have is

Type: Booking with nodref field Artist (linked to type Artist)
Type: Artist with noderef field Agent (linked to type Contact)
Type: Contact

test case was:

Booking = booking #1
it has Artist = noderef link to Alan Parsons
Alan Parsons has noderef link to Joe Smith

issue above DOES work, if i search on "parsons" it does find "booking #1"

but sadly, searching on "smith" does not.

we need a related content module.. lol.. where module recursively goes through X levels of noderef relationships to index to parent.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

kevinob11’s picture

kevinob11 commented
Status: Closed (fixed) » Active

This doesn't seem to be working for me. I have tried setting the cck search index to title and full node and don't seem to have any positive results. An explanation of my use case is below.

I have Node 1 and Node 2. Node 1 references Node 2. When I search by entering the title of Node 2 I only return Node 2, I would think if this is working correctly I should return Node 1 as well.

Thanks, any help is appreciated.

kevinob11’s picture

kevinob11 commented

I just tested this on vanilla D6 and it is working correctly there. I know this isn't a cck issue but does anyone know why this wouldn't be working in a stock atrium site?