Does not work correctly with nested views

This is great; thanks! But is there any way we could do the same for the opposite scenario? That is to say, the parent view does not have the Views Load More pager, but the child one does. I imagine that might work already, except for the case (my case) when the parent view uses AJAX exposed filters...

Sorry if this is perceived as hijacking this thread; that's not the intention but it does seem like a related matter.

Yes, I did try the patch in this thread with my case without luck (same thing). However the other issue # you pointed out seems even more appropriate to my particular problem. I'll go give your patch over there a try. Thanks so much for helping out; I really appreciate it!

Sorry to come back here, but finally I do think it's relevant to this issue. Here's what I'm looking at (summarized):

<div class="view *views-classes*">  --parent view base div--
  <div class="view-filters"></div>  --parent views' exposed ajax filters--
  <div class="view-content">  --parent view's content div--
    --some content from the parent view--
      <div class="view *views-classes*">  --child view base div--
        <div class="view-content">--some content from the child view--</div>  --child view's content div--
        <div class="item-list">  --child view's pager div--
        <ul class="pager pager-load-more"><li><a>pagerlink</a></li></ul>  --load more pager--
        </div>
      </div>
  </div>
</div>

Note that the *views-classes* above sometimes include "jquery-once-1-processed", which I know plays a role in this problem. When I remove the classes from either of the base divs using their respective tpl.php files (<div class="<?php print $classes; ?>">) - it breaks and the other functionality works. So if I remove them from the parent, the filters break but the pager works, and visa-versa.

Thanks caiosba. This patch doesn't hurt, but doesn't help either. What ends up happening is that both views work great together, except the Views Load More pager refreshes the information instead of adding to it (which is what was happening before the patch, as well).

I fixed this in a different approach and it's working fine.

The patch from #7 and #8 doesn't work. It's all compleatly annoying with all this nested views issue and I wrote a fix (it could be a little dirty but I don't care so if you have something to say about my code please f** off) but it works.

Here I am again. Just put small fixes to this.

The patch #10 works fine.

I have another situation. In a views header i have a views field view that use a pager "Page by date". My general views use pager "Views Load More". Then click on Load more link, the content of pager (Page by date) is append to Load more pager.

before apply load more:

<div class="date-nav item-list">
    <div class="date-heading">
      <h3>January 2014</h3>
    </div>
    <ul class="pager">
      <li class="date-prev">
         <a href="href" title="Navigate to previous month" rel="nofollow">« Prev</a>
      </li>
      <li class="date-next">
        <a href="href" title="Navigate to next month" rel="nofollow">Next »</a>
      </li>
     </ul>
</div>

<ul class="pager pager-load-more">
   <li class="pager-next first last">
     <a href="href">Load more</a>
   </li>
</ul>

after load more:

<div class="date-heading">
      <h3>January 2014</h3>
</div>
<ul class="pager">
     <li class="date-prev">
        <a href="href" title="Navigate to previous month" rel="nofollow">« Prev</a>
     </li>
     <li class="date-next">
        <a href="href" title="Navigate to next month" rel="nofollow">Next »</a>
     </li>
</ul>
<ul class="pager pager-load-more">
   <li class="pager-next first last">
      <a href="href">Load more</a>
   </li>
</ul>

I fix my issue using patch #10 + my patch.

In my case the views load more pager didn't work, because the default views ajax pager implementation doesn't work for nested views.
Patch #15 of the following views issue solved this first problem: https://www.drupal.org/node/1877446.
Next up: views_load_more and nesting..

I made a different patch, which also makes the pager work, but a bit more generic than #12.

It works for a parent view with the load more pager, and child views with also the load more pager.
Make sure the parent view has a different pager ID than the child views and that the patch for views mentioned in #13 is applied.

Improvement on #14. (After clicking load more on the parent view, newly loaded child views with pagers didn't work).

#15, FYI: Omega 4 removes "item-list" wrapper, so #15 is too specific, IMHO. At other patches, this one works okay:
wrapper.find('.pager').replaceWith(new_content.find('.pager'));

I think the underlying issue with nested views is line #42 of views_load_more.module:

    // This is a work-around for allowing exposed for on the page.
    if ($view->query->pager->current_page == 0) {
      return;
    }

The views suggested solution to add unique Pager ID into the nested one will always fail due to the above return, since nested pagers will always start with 0, e.g.: 0,1, etc.
Any idea to solve this?

#15 worked for me.

Thanks,
Ashish

#13, thanks for testing. In my experience Omega removes a lot which breaks functionality in contrib modules (for example the edit module).
Maybe we can make the pager class a setting.

#19, there is a patch marked RTBC, as mentioned in #17 above:
https://www.drupal.org/node/1644036

Maybe you can incorporate it here to get a bigger picture, or drop it if the mentioned thread gets in.
I am not sure if this is a dup of the other while both seem addressing the similar lines ;)

I can confirm that #15 works.

Finding that there are a bunch of semi-related issues in this queue that need to be managed as a whole somehow..

I've committed #15 to 7.x-1.x-dev.

I've also reviewed #1644036: Pager disappears after AJAX reload. The patch here should also fix #1644036: Pager disappears after AJAX reload. This patch fixes that issue as well as considers nested views.

Thanks everyone!

I've tested the patch in #15 on a search-api view with nodes, with load-more set to show one item per page. In my case there were three items in total. The first press on load more works as expected, showing the second node. Subsequent clicks however simply add that second node to the overview over and over again, never showing the third.

I've tested this by applying that patch to the latest stable release, but the issue is also present in the latest dev, in which it is included.

I have the same problem, just installing the dev version of views_load_more that contains the patch in #15, breaks the views_load_more functionality for me.

Specifically the JS code responsible for replacing the pager and the content does not work properly, aka

var content_query = targetList && !response.options.content ? '> .view-content ' + targetList : response.options.content || '> .view-content';

and

var pagerWrapper = wrapper.find('> .item-list');
var newPager = new_content.find('> .item-list').html();
pagerWrapper.html(newPager);

does not work. The '>' bit in the selectors make the returned selectors empty.

I'm not sure, but maybe this is related to the jQuery version used, I have jQuery Update to update to jQuery 1.10.

Removing the '>' bits makes the code work, but I guess that breaks nested views functionality.
I think a new patch has to be created which takes into account both nested views and simple views.

@FreekVR odd. I am able to reproduce the issue using the latest dev just as you laid it out. Reviewing possible cause now.

@FreekVR @Placinta. So this is weird. Try this for me would you? Grab the latest views_load_more dev, and on your view, turn on the full pager and turn off AJAX so as to test with the default views pager. I'm seeing the same weird behavior with the views default pager, where the first page shows the contents of what should be the last page.

That is to say, looks like there may be a views bug here? Not sure, still reviewing.

@FreekVR @Placinta Ohhhh OK. I see what was happening for me. So in my case, my view was ordering on modified date and my conent was build with devel generate. That meant that some nodes shared the same timestamp, which means that MySQL can come up with different orderings each time.

So, make sure your sorting is on something unique, then make sure that your paging works with a default pager. Then if it still doesn't work with Views Load More, let me know the details, or let me know it's working (hoping it's the latter, lol).

I installed the dev version on a clean-ish Drupal instance, and it worked. Then I figured out why it didn't work.
The pager JS code expects the .item-list to be directly in the wrapper of the view.

var pagerWrapper = wrapper.find('> .item-list');
    var newPager = new_content.find('> .item-list').html();
    pagerWrapper.html(newPager);

Whereas in my case it was not a direct descendant, but rather in another div, so the selector failed.
The problem is that the pager selector is hardcoded. There should be an option to set the pager selector like you can set the content selector in the Views UI.
Otherwise if you change the markup of the pager, it won't work.

More people confirmed #1644036 worked even with Omega4 which removes the '.item-list' selector, as I mentioned in the above issue #8996509.
Sorry, I am not sure I follow why you don't incorporate the patch in that issue, which is already confirmed working by many, with this one.

@Placinta yeah that would do it. I agree there should be an option to set the pager selector. I'll work that in.

That's the trouble with this module and supporting it, as soon as the views markup changes, things break. I think providing an option for specifying the selector for both the rows container and the pager will at least give people a way to adjust the load more pager on their own to be able to work with their markup. That together with updating some documentation should make things clearer.

Ideally, for future, it would be nice if there was a way views_load_more could allow whatever markup changes people want to make, while at the same time maintain a level of control to be able to know where the rows are in a given view and where the pager is.

@Placinta see https://www.drupal.org/node/2327947. Latest in 7.x-1.x now provides an option to specify the pager selector.

@gausarts thanks for pointing that out. I've incorporated the suggested JS from #1644036. Please checkout the latest 7.x-1.x branch and test if it's working for you.

Yep, using latest DEV + specifying my own selector for the view content, and leaving pager selector empty (aka using the new patch that you applied) works properly for me.

Thanks @Placinta. Closing as fixed for now.