If node 2 links to node 1 (both with a standard input format) then {search_node_links} will contain an entry for sid = 2, type = 'node', nid (i.e. the target) = 1.

A few other clever things happen as well, e.g. search scores for node 1 get elevated.

However if node 1 is PHP input format then all of this is skipped, because of this line:
http://drupalcode.org/viewvc/drupal/drupal/modules/search/search.module?...

But this check, which is supposed to avoid "redirect bugs", is actually redundant, for 2 reasons:
- the target node's PHP code (if any) is not even loaded, let alone evaluated, so the redirect would not take place when indexing node 2
- the redirect "bug" would in any case be encountered when indexing node 1, which the check here would not prevent

Also the check has been removed from 7.x (tho' not the comment!):
http://drupalcode.org/viewvc/drupal/drupal/modules/search/search.module?...

Files: 
CommentFileSizeAuthor
#15 search_module.patch674 bytessidharthap
#2 search-links-664124.patch980 bytesgpk
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch search-links-664124.patch. See the log in the details link for more information.
[ View ]

Comments

gpk’s picture

Title:(search_node_links} entries are not created if the target is uncachable (e.g. PHP input format)» {search_node_links} entries are not created if the target is uncachable (e.g. PHP input format)

Reference:
The issue which introduced this check: #28159: Advanced search features (see the very first patch there)
The issue/patch which removed it from 7.x: #506218-21: Remove collapsed comments and tidy up settings. TBH I'm not sure why it was removed there, since the change seems unrelated to that issue.

Related: #205202: Fix search index link handling for non-existent nodes

gpk’s picture

Status:Active» Needs review
StatusFileSize
new980 bytes
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch search-links-664124.patch. See the log in the details link for more information.
[ View ]

Have deployed this on a live 6.x. site, so far so good, no problems encountered and node links are now present where they were previously absent.

I'm re-indexing the site to make sure that all the links get created in {search_node_links}.

jhodgdon’s picture

Version:6.x-dev» 7.x-dev

This needs to be fixed in Drupal 7 first, then back-ported to Drupal 6.

Status:Needs review» Needs work

The last submitted patch, search-links-664124.patch, failed testing.

gpk’s picture

Version:7.x-dev» 6.x-dev
Status:Needs work» Needs review

@3: The problem is not present in 7.x (see original post and #1). And the redundant comment in 7.x was removed in #664130: Comment in search module shoud have been removed.

The patch at #2 has been in place since December and the Views backlinks block now works as expected in consequence where previously some backlinks were missing.

jhodgdon’s picture

Status:Needs review» Reviewed & tested by the community

Sorry! I guess I didn't read #1 carefully enough.

So it looks like we should see if we can get this into D6.

Gábor Hojtsy’s picture

Status:Reviewed & tested by the community» Needs review

@jhodgdon: have you been able to test this out? From the comment it sounds like the code is executed later on condition that it was linked to the node, no? (I'm not too informed on the search API :)

jhodgdon’s picture

I think that must have been a slip of my finger to mark it RTBC rather than back to Needs Review in #6.

Sorry. I will take a look, though I don't know when... thanks for double-checking Gábor.

allan1015’s picture

Issue tags:+search, +backlinks

I cannot get the search_node_links to populate at all.
I have modified the search.module with the patch above (manually) as well as added a || true to the
if (filter_format_allowcache($node->format) ) { line suggested in another thread

These are pages/stores that I have converted over from an old postnuke - and no other issues, searches do find content, words, etc.

I have disabled/removed, re-enabled search module to start from scratch
I have made sure cron runs and all that.

Regardless the node links table remains empty

The links look like this

Is there some just really basic issue, config I am missing?????

Allan

gpk’s picture

@9: your issue looks like it may be different. Unless, that is, you are using PHP input format everywhere. This one is specifically when the PHP input format (provided by the PHP module, which is disabled by default) is used on nodes. Can I suggest opening a new issue to discuss your particular problem? Also the link you have posted did not render (put in in <code> </code> tags so that it doesn't get stripped out).

I can confirm that on a site with several hundred nodes (many of which don't link to other pages on the site) we have a few hundred entries in {search_node_links}.

Thanks for the mention of "other threads" by the way, the following looks to be a dupe of this issue:
#513870-12: What links here tab / backlinks not finding nodes.
Also #205202-10: Fix search index link handling for non-existent nodes mentions the problem.

allan1015’s picture

@10 - Ok, new issue, and update information adn findings opened here:

http://drupal.org/node/826922

Sree’s picture

#2: search-links-664124.patch queued for re-testing.

Sree’s picture

{search_node_links} entries are not created due to “filter_format_allowcache” in D6 - is there any approved patch available for this?

Status:Needs review» Needs work

The last submitted patch, search-links-664124.patch, failed testing.

sidharthap’s picture

StatusFileSize
new674 bytes

Here is a latest patch file.

lucuhb’s picture

I tried the last patch #15 and now the {search_node_links} is updated when a node is updated and cron runs: backlinks are now correctly displayed (only for links from updated nodes).

Is there any problem to apply this patch on a production site ?
Is there a solution to get all backlinks even from nodes not updated since the patch ?

In the original line

<?php
 
if (filter_format_allowcache($node->format)) {
?>

the response seems to be false due to the {filter_formats} table where the filtered HTML has "0" in the "cache" column (in my case at least).

Is this cache value define by default or can be configured, and where ? What other impacts of this value ?

sidharthap’s picture

Hello

You can apply this patch to production. After applying the patch you have to re index the entire site.
This will not create any problem. This issue is fixed in Drupal 7.

lucuhb’s picture

OK, thanks for your response ... and for your patch !

jhodgdon’s picture

Status:Needs work» Closed (won't fix)

Sorry that this issue didn't go anywhere for Drupal 6.x. The Core Search module was without a volunteer maintainer for a couple of years.

At this point, I think it is too risky to apply this patch to 6.x -- we're really only doing either very very safe fixes or critical bugs. So I think I'm going to just have to mark this as a "won't fix" at this point.