What links here tab / backlinks not finding nodes

did you testet whether the search feature works? Views just uses this feature!!

Therefore have a look in {search_node_links} table - whether the links exists there...

            if (preg_match('!(?:node|book)/(?:view/)?([0-9]+)!i', $path, $match)) {

-> the intern links works currently only for node/$nid paths, thats NOT something which does views, accept this.

as far as i read the search.module code, no

i've used backlinks on other sites but this time i can't see what's wrong:

- by now i'm using the default backlinks views
- node A1 is referenced by node B via a node-reference field of all nodes of content type A
- the link to A1 is created on node B
- run cron
- if i search the site for A1 node title both pages (A1 itself and B) are found
- but no backlinks are found at A1 node page (neither in the block, nor in the backlinks page node/nid/backlinks)

i have no clue... any help is appreciated...

as i sead above.

This function just searches through the text with a easy regex. So you have to have links in your body, having "node/@number" as href tag.

but i do have links in the body page. they're created through a node reference field in node type "B" that references node types "A". the links use aliases, of course.

they're correctly indexed, proof is that a normal search finds both referrer and referred.

the only problem is that the "What links here" block and page are empty...

ah search uses node_view.

But you cannot use aliases, thats how it is, views cannot do there anything.

i'm afraid, you're wrong, of course you can use aliases. nodes don't lose their NID when they're aliased.

what surprises me is that on another drupal installation on a different server i use node reference to create a link to page A on page B and a backlinks view to link the referrer B page on page A. all with url aliases. and it works.

i'll try again to reset the default backlins view (already did it once) and see if something got wrong with the database.

The search_index() function does a check on filter_format_allowcache($node->format), where $node is the linked node. If the check returns false, the link will not be indexed.

Troubleshooting:
Find the line of code in search.module where this check happens, and add "|| TRUE" to bypass the check. Re-index your nodes (in Site configuration > Search settings), and run cron. If it works now, you are one step further. I assume there is a reason for the check, so I don't know if it is safe to remove it. But for troubleshooting it's a good idea.

The problem is reported here,
#205202-10: Fix search index link handling for non-existent nodes
but probably deserves its own bug report.

Maybe this issue is exactly the right place, so here you go:

If filter_format_allowcache($node->format) returns false, the "what links here" search (in views) doesn't work.
I totally don't get why this check is needed. Especially, if the node has some CCK textareas and the body field, and each has a different format, then what is the relevance of this check?
The most notable effect is that I spend hours of debugging to find out why the "what links here" views argument doesn't work with my site. I added a "|| true" to the filter_format_allowcache condition, and now the indexing works. Tataa!

EDIT:
If you can confirm the problem, we can make this issue a core bug report.

EDIT (II):
This is where you should look:
#286263-57: Make search indexing smart to handle nodes wth php redirects

thank you very much. i'm not working on that project anymore but i'll definitely make a check and will report back.

I can verify that getting rid of the If filter_format_allowcache($node->format) check fixes backlinks. I had it working and then it stopped working and wasn't sure why.. forgot i had patched this just prior to doing core upgrade (and therefore lost the patch).

before patching a 2nd time i had same results as reported above.

url in my page is wiki/testpage1 (url_alias for node/567).

doing a std search on testpage1 returned both the page itself and the page that included the link in the body, yet backlinks block showed nothing.

after repatching, reindexing and running cron a few times.. backlinks block now shows link.

not sure what this is used for or if the bug is in search (core) or in views. For some reason; if search can find the links (without the patch) - it would seem like views should be able to

I am on D6.16 and Views 6.x-2.10.

I have search, Views 2 and Views UI modules enabled. I have never used Freelinking.

When I click on the "What links here" option in a node I get the result "No backlinks found." - when lots of backlinks do exist.

In all my nodes I use the href for the alias name as determined by pathauto. I do not use node/xxx as href.

I have Clean URLs enabled.

My {search_node_links} table has zero rows.

Any suggestions as to what I should do to get Views 2 backlinks to work?

Here's my suggestion (patch to search.module included)

As dereine wrote in #2, the "problem" is the simplistic check in search_index, narrowing the indexing to nodes with a path syntax node/xxx or book/xxx.

My proposition: revert the alias to the original node path for the purpose of the check. This is what does the included patch.

Patches to search module aren't going to do anyone any good in the Views queue. :/

I'm not a programmer, so some parts of this thread mean little to me. Sorry.

So in simpler language, would I be right in summarising that this views backlink functionality does not work with pathauto aliases. Hence mysite.com/node/123 should work, but a link to the same node using mysite.com/my_node_example_title would not work? If this is so, could this be changed to make it work, as pathauto is so widely used? If it cannot be recoded, perhaps the description for the backlinks view at admin/views could be changed to make this clearer to potential users.

Thanks to everyone that has helped develop and share Views module.

Related: #664124: {search_node_links} entries are not created if the target is uncachable (e.g. PHP input format). From the discussion above (#10, #12) it looks as though this might well fix this issue.

In my case, none of my node have PHP filter applied, so http://drupal.org/node/664124 is not relevant.

Also my Drupal install is not in a subdirectory of my domain, so http://drupal.org/node/826922 seems not to be relevant either.

My {search_node_links} table has zero rows. Any further suggestions as to what I should do to get Views 2 backlinks to work?

@20: I am using the backlinks block on a site that uses pathauto, and everything works well. The only ones I was having a problem with were the PHP code nodes, hence 664124.

Can you post an example of a complete <a> tag from your site in case there is something I'm missing, because at the moment I can't think why this wouldn't be working for you unless you have some additional filters or arguments in the View that are interfering.

Here is a snippet from one of my pages...

<strong>We do not:</strong>
<ul>
<li>contain anything that you wouldn't want children to see, hear or use. Read our <a href="content_statement">content statement</a>;</li>
<li>disclose information from, or about, visitors with their consent;</li>
<li>sell, rent, exchange or disclose our <a href="newsletter">newsletter</a> mailing list;</li>
<li>use pop-ups, hidden images or 'web bugs'.</li>
</ul>

What happens if you put a / at the beginning of the hrefs?

Thanks for the suggestion. I have changed all the links on the node from which the above example came to have preceding /. The links all still correctly go to the same place when clicked. Then I re-indexed site at /admin/settings/search, and my search_node_links table still has zero rows. Any further suggestions please?

@25

If search_node_links is empty views cannot do anything. You have to run cron to fill it up! It depense 100% on the table entries. There is no patch which can solve this.

The patch is not attached. (i can't access the file)
Can you please reupload the patch?

subscribe

subscribing ....

The backlinks work swimmingly throughout my site using pathauto EXCEPT when the original node's title includes weird accent symbols, such as ü o é. These symbols are being pulled into the pathauto and then seem to break the search.

And pathauto won't let me manually change the URLs to take out these symbols (I know, that's a pathauto problemm but I'll mention it here as it affects my Backlinks.)

Hmmmm.

the patch from http://drupal.org/node/664124#comment-5139896 did it for me.

I had to reindex the site.

my 2 cents w/o reading the above discussion - on a drupal 6.25 when I apply the http://drupal.org/node/664124#comment-5139896 patch and reindex - the search module begins populating the search_links table after a site reindex via the settings or drush and several cron runs to fully reindex.

its not view's fault but search.module's...