Node Relationships disables Search results pagination

Re: "search results are limited to 10 and no pager is shown"

hmm... I'm not sure to understand because AFAICT, The Node Relationships module does not alter anything related to any search function. Could you please clarify what do you mean by "search results" and which "pager" are you referring to exactly?

I can confirm that I see an identical problem. Just as zachwood described it. I can sometimes see the pager on the first page of the search results but when I click on any of the pager links the pager is missing on the new page. I just disabled the node relationships module and re-enabled it again to find that the pager is now absent all the time on my search results.

This problem has gotten worse on my website. I thought it was only restricted to search results but it now appears to break the pager on views that display my nodes alphabetically. I have been doing some debugging on this and have a couple of questions. I can see using xdebug that the following functions get called. I have nested them to show the sequence of calls from inside other functions.

theme_noderelationships_formatter_default()
    noderelationships_settings_load()
        noderelationships_get_back_reference_regions()
        noderelationships_settings_list()
        noderelationships_settings_region_sort()
            noderelationships_settings_element_sort()
    noderelationships_backref_render_view() *
        theme_noderelationships_backref_view()

noderelationships_views_pre_view()
    noderelationships_customize_backref_view()
        noderelationships_get_localized_content_type()
            noderelationships_get_i18nstrings()
    noderelationships_get_backref_view_overrides()

It appears to me that these functions construct the view for the list back reference nodes. Assuming that this is correct, what I do not understand is why these methods get called when the nodes are displayed in teaser format. Surely this is very inefficient as we do not display the back reference view for any of the nodes when they are shown as a teaser. Maybe the views hooks require the back reference view to be constructed all the time or maybe this is the source problem?

I find that when I changed the noderelationships_backref_render_view() function to return an empty string the pager is restored and is working correctly. This narrows the problem down some. I thought it might be related to line 147 (shown below) which is inside the noderelationships_backref_render_view() function so I commented this line out by itself.


// Assign a different pager element for each view in the same page request.
$view->display_handler->override_option('pager_element', $pager_element);


But this did not fix the problem. As the line changes the pager_element I thought it must be related to the source of the bug. Anyway, I am now stuck and thinking about what to try next. Can you offer any advice? I really need to try and resolve this one very soon.

Subscribing.
Have the same problem with:
Drupal 6.19
Node relationships 6.x-1.6

Subscribing. Same issue. Same specs.

I found it when building views of recent nodes. The recent nodes of the target node type (from reference) will not display a pager. However, the recent nodes from the referencing node type will display pagers. Also have the same issues displaying top ranked (fivestar) targeted node type.. while top ranked targeting or referencing nodes are getting the pagers.

@zachwood: Re: "after you enter a search term and submit the form"

I'm afraid I cannot still see the relation. Is that form the one implemented by the core search module? If so, how it can be affected by anything views related? Drupal core search does use views.

If it is not using the core search module, then which kind of search engine are you using? Is this common to everyone else?

I'm not having this problem on drupal core search. Only on views-based pages.

Found something interesting: the pager works if the row style is set to 'fields'. It disappears for the 'node' row style, however.

The Node Relationships module may alter views, but only those that are tagged with the words noderelationships_noderef or noderelationships_backref. Let's say these tags are reserved for Views that are to be used by the Node Relationships features only.

Is it possible that you are sharing a Node Relationships view for the search results?

Out of curiosity: which module/method do you use to replace the Search results with a view?

Just found another piece of the puzzle: The pagination only dis-appears when logged in as admin! I've logged in as a test user, and the pagination is fine. Also, when not logged in at all (ie: anonymous user) the pagers are there.

To answer your question: no, not using Node Relationships as part of the view at all. In the simplest case, the view only has these elements:
Display: Page
Use Pagers: yes
Items per page: 10
Row Style: Node ->(teaser)
Sort Criteria: Post Date (Desc)
Filters: Node Type- Published: Yes, Node Type: [selected node type]

A summery of current (consistent) conditions on my site:
Logged in as admin
View based page
Row Style: Node
View contains target of Node Relationships node reference (exclusively)

At this point, everything works fine to the end user, and I'm happy. Issue is not critical for me anymore. Thanks SO MUCH for all your great work markus_petrux!

Fairly certain the node relationships within one of my node types breaks view pagination when in node > teaser mode.
If the content type with the relationship is excluded the pager works fine and if I'm in view style field it also works fine.

Appears that the pager ID of the noderelationships_backref views wipe out the one for the containing view.
Not 100%, but have been chasing this issue for a while and this seems the culprit.

(Drupal 6.22, Node Relationships 1.6)

I'm now sure this is the problem.

I removed the pager entirely at "admin/build/views/edit/noderelationships_backref" and now I can use this content type in teaser mode again.

Seems the pager element IDs are set by the position in the views result, this might need a way to be altered.