Skip Navigation

[Resolved] Problems with AJAX Infinite scrolls and Masonry

This thread is resolved. Here is a description of the problem and solution.

Problem:
It seems that while masonry JS works perfectly fine with all AJAX pagination methods on a Toolset View, it conflicts with infinite scroll.
The behaviour is that it seems masonry "takes longer" to "kick in" on infinitely scrolled views, while other AJAX paginated views do apply masonry layout immediately to the output

Solution:
Masonry needs to adjust the new content, but when the pagination starts there is no new content to adjust just yet.

Hence, Masonry effects kick in when the AJAX pagination of Views replaces the old with new content before the pagination completes.

Until pagination completes the new masonry layout is not final, hence it can't be completely built.

If you use a Views pagination effect, anything that you do on the new View output should wait until the pagination is done.
This is the same when applying the masonry library to a layout on the first page-load: it needs to wait until the page is loaded. You should never ever apply a library over an HTML tree that is going to change.

To reduce the time until results getting applied to a library, you can always reduce the animation time to 0. New content will get masonry applied as soon as it gets loaded, but ONLY once it is loaded. That can not be avoided.

This support ticket is created 6 years, 6 months ago. There's a good chance that you are reading advice that it now obsolete.

This is the technical support forum for Toolset - a suite of plugins for developing WordPress sites without writing PHP.

Everyone can read this forum, but only Toolset clients can post in it. Toolset support works 6 days per week, 19 hours per day.

Sun Mon Tue Wed Thu Fri Sat
- - 14:00 – 20:00 14:00 – 20:00 14:00 – 20:00 14:00 – 20:00 14:00 – 20:00
- - - - - - -

Supporter timezone: Asia/Ho_Chi_Minh (GMT+07:00)

This topic contains 20 replies, has 2 voices.

Last updated by Beda 4 years, 10 months ago.

Assisted by: Beda.

Author
Posts
#952426

Hi, just purchased this great toolset, before I was here I have been using a lot of plugins to get close to what I want
but there are some key features missing, which toolset seems can get all of them done as a whole package, except how to display the post in a nicely formatted grid.

I know this is probably custom css or something, but since I do not know much about it,
Basically I would like the view to display my post like the example here,
hidden link

You can also see in my own page, which is not done with toolset yet, but as a nice grid
hidden link
Each of the post is using featured image as the main element on the page, the featured images are not in same size & ratio, and I would like to display the full image without cropping, and for each post will be automatically align with the neighbouring post,

Currently after a few days explore what I can get with toolset now looks like this, with huge gaps in between the vertical space.
hidden link

By the way I'm using WPbakery to do the layout

Any help or direction would highly appreciated.

Best,

Tye

#952800

Generally, in Toolset you would use the Loop Wizard and for example use the Bootstrap Grid with (several) columns.
This is probably the closest you can get to such layouts as the masonry, with just a few clicks in Toolset.

More than that requires Custom HTML and CSS at least or also JS.

But the layout you show here:
hidden link

Should be possible like that in Toolset.
I think a similar layout even would be possible with simple Rows where you add the Images in one column.
But, that is not nice, of course.

In Toolset alone, as it is, the Bootstrap Grid is the closest you get to that.
What I did in past was including other libraries with custom code to my custom themes and then load them, which allowed me to use their HTML, CSS and JS in the Loop of the View.
For example, I included MDBootsrap (Material Design with Bootstrap) and then used their galleries.
hidden link

But this is not included within the Toolset natively, however no issue to use if enqueued properly according the WordPress Codex.
hidden link
Note that in these cases, one does not load Bootstrap with Toolset, but chooses to load it from the theme.

Related to this:
Currently after a few days explore what I can get with toolset now looks like this, with huge gaps in between the vertical space.
hidden link

This looks rather like an issue with mixed markup and syntax, eventually even broken syntax or too much content for too small areas.

Can you try this:
- Create a new View
- Choose to display the Posts where you have the images stored
- Choose to display a Loop with the wizard (Bootstrap Grid) for example
- Insert a Field (Image Field or featured image would make sense here)
- Complete the loop wizard and now edit the single ShortCode for the image to match the size you want.

Likely it is best to use predefined image sizes so you can make sure there is no unexpected paddings.

In the libraries I mentioned above for example, the nice they look the complex they are.
For example in one kind of gallery you need to store the images all the same size (no matter what size, but the same)
Otherwise the gallery simply doesn't look nice.

The same with a GRID where you want all images lets say "touch" each other in the grid, you will need some boundaries set, so you can set CSS customizations if needed that do not change for each image / border of grid's cell.

Please let me know if you need further help with this

#953803

Hi Beda, thanks for your detailed reply.
I found a solution to get masonry grid, but I'm having difficulties applying to toolset views, I tested it out side on a page and it works,
The grid is done thourgh JavaScript here,
hidden link

And I would need to wrap each post with the code
<div class="grid">
<div class="grid-item"> MY POST GOES HERE</div>
</div>

I'm not sure how to combine this with the toolset views, shall this go into the Loop Editor or Content Template?
Currently I'm using Wbakery to generate the template.

I generate My view using a 3 column bootstrap grid and the editor looks like this,

[wpv-layout-start]
[wpv-items-found]
<!-- wpv-loop-start -->
<wpv-loop wrap="3" pad="true">
[wpv-item index=1]
<div class="row ">
<div class="col-sm-4">[wpv-post-body view_template="Loop item in View 1"]</div>
[wpv-item index=other]
<div class="col-sm-4">[wpv-post-body view_template="Loop item in View 1"]</div>
[wpv-item index=3]
<div class="col-sm-4">[wpv-post-body view_template="Loop item in View 1"]</div>
</div>
[wpv-item index=pad]
<div class="col-sm-4"></div>
[wpv-item index=pad-last]
<div class="col-sm-4"></div>
</div>
</wpv-loop>
<!-- wpv-loop-end -->
[/wpv-items-found]
[wpv-no-items-found]
[wpml-string context="wpv-views"]No items found[/wpml-string]
[/wpv-no-items-found]
[wpv-layout-end]

Thank you!

#954396

1. And I would need to wrap each post with the code
<div class="grid">
<div class="grid-item"> MY POST GOES HERE</div>
</div>

I'm not sure how to combine this with the toolset views, shall this go into the Loop Editor or Content Template?

This you would do in a View.

A View will allow you to query a specific post type and output as many of them you have/want.

Then, in the View Loop editor, you can insert the HTML that needs to repeat.
You will this HTML tag:

<wpv-loop>

</wpv-loop>

Everything within those 2 tags repeats.
Everything outside them, but within the [wpv-layout-start]/[wpv-items-found] will be output just once.

So, your Loop could look like:

<div class="grid">
<div class="grid-item"> [wpv-post-title] and other shortcodes</div>
</div>

Since you now use another compiler, you cannot use the Bootstrap Grid, but need to use your new HTMl syntax required.

Note that, sometimes, you need to do this:

html (not repeating)
-- repeating inner HTML (single tiles)
Losung html (not repeating)

In a View that is possible, you would just move the HTML that you need once out of the loop, right?
(See above explanation of how the loop works).

But, there is a problem.
Views, produces some default HTML around its loop.
So, that HTMl would destroy any other wrapping HTML and especially usually it destroys other JS - since that JS listens to very specific HTML outputs.

So, if in case you need to use this code:

<div class="grid">
<wpv-loop>
  <div class="grid-item"> [wpv-post-title] and other shortcodes</div>
</wpv-loop>
</div>

Remember that you may see unexpected output.
To fix that, you can either apply custom code (ask me, if yo need it, I can provide it) or you can wait for a future release of Views where that will be possible to adjust.

Please let me know if you need more info.

#955677

Thanks again, I think I have some progress here,
I switched to a simpler css method to do the masonry, the source is here:
hidden link

And I simply wrapped my loop with <section>:

<!-- wpv-loop-start -->
<ul class="wpv-loop js-wpv-loop">
<wpv-loop >
<section>
[wpv-post-body view_template="Loop item in View 1"]
</section>
</wpv-loop>

<!-- wpv-loop-end -->

This works great except that now I want to do infinite scroll, or load more, but when I followed the infinite scroll steps in the document, the grid is messed up on every load, as you can see my test link here, when I adjusted the browser window, it comes back to normal
hidden link

For each post, I'm using the following shortcode on the template section, could this be the problem?

[vcex_image_banner heading="[wpv-post-title]" caption="[types field="brand"][/types]" image="[types field="featuredimage"][/types]" content_align="center"]
<br>
[formidable id=22 postid="[wpv-post-id]"]

Can you please advise how to fix this? Thanks!

#955680

Tested this link hidden link
on multiple browser, all act differently....

#956340

This works great except that now I want to do infinite scroll, or load more, but when I followed the infinite scroll steps in the document, the grid is messed up on every load, as you can see my test link here, when I adjusted the browser window, it comes back to normal

This is because infinite scroll as any other such event works with AJAX.
The Grid you use has some JS that acts on it.
When the View loads new results with AJAX, the JS of the grid is not fired again.

That can be solved by adding the function to our JS Front end events.
Those you can insert in the JS Editor of the Front End Search Section.
There is a button that lets you add your custom JS functions (or those of any other code like a masonry grid) and fire them on certain events like, when the next page results are loaded, or a search is triggered, etc.
The GUI that figures up when you press the "JS Front End Events" button, will be self-explaining.

After the required functions are added there, they'll fire again when you use the View's AJAX.
And the Masonry grid should work fine

To know what functions you need to fire, you best would contact some support member or expert of the Grid you use, they can determine what functions you need to reload.

However, I think even in the Toolset Support Forum you will find solutions, although the often are custom:
https://toolset.com/forums/topic/masonry-layout-broken-after-ajax-reload-parametric-search/
https://toolset.com/forums/topic/masonry-js-issues-after-search-filter-ajax-refresh-but-ajax-pagination-working/#post-341911
https://toolset.com/forums/topic/masonry-grid-2/#post-575879

#956676

Beda,
I'm not using java to do Masonry, it's pure css, please see the reference below.
hidden link

Every time I do infinite scroll, there's a shift of the posts, but once I re adjust the size of the browser, the grid will come back to normal. Can you help with this? Thanks.

#957325

OK, ignore what I said about pure css, I got it sort of working with hidden link
and with extra js in JS Front end events
The minor issue I have is that, and you can see it in here hidden link

Every time the infinite scroll is fired, the gird gets messy for 1 second and then back to normal.
It also scroll back to the top, which makes the infinite scroll less useful.
Is there a way around to fix this? Many thanks, I think I'm almost there.

Best,

Tye

#957884

Ok, this looks different from what I suspected.

I know the behavior, you can see the same or similar when you create a simple slider in Views, and paginate either automatically or sliding manually, it seems there is a lag that provokes the images to (in a slider) jump up and down.

I Apologize I thought it's due to the JS not loaded, this seems something else.

It may also be from Layouts, I have seen the same issue in some cases there, and you seem to use it on this website.

Now, usually in a native view that is due to a wrong (and which can be corrected) setup or HTML.
In this case here we deal with an external library with which I do not have lots of experience, I use more bootstrap.

Could I ask for a copy of this, to play around with it locally and find out what's wrong?
I think this could benefit other users as well, the output methods in Views Loops are something that many people often ask for some more freedom, so this could be a good moment to try and provide some simple solution to the issue

I will enable a private reply in case you agree for me to look into the install locally:
https://toolset.com/faq/provide-supporters-copy-site/

I think I already know what it could be, there are some JS errors pointing to a " Found 6 elements with non-unique id #field_4hcxy:", [DOM] Found 6 elements with non-unique id #field_5vwod:, etc, which means, probably you have some ID attributes in the Loop now that you would need to make unique.
That can be done by populating them for example with a [wpv-post-id] shortcode so it'll be unique for each of the output elements

This - if the scripts expect unique ID's, can then break the flow of the script and break the output.

Thanks!

#1069210

This ShortCode is broken:

[vcex_image_banner heading="[wpv-post-title]" caption="[types field="brand"][/types]" image="[types field="featuredimage"][/types]" content_align="center"]

It is A) not allowed by WordPress not nest ShortCodes and B) Toolset makes it possible to some extent but that still does not solve WordPress's strict conditions and parsing mechanics.

The above ShortCode is broken as it uses Double Apostrophes ("") and nests again double apostrophes.
That can only be done when you nest either Double or Single apostrophes, hence:

[vcex_image_banner heading="[wpv-post-title]" caption="[types field='brand'][/types]" image="[types field='featuredimage'][/types]" content_align="center"]

Notice all internal (nested) ShortCodes now use single apostrophes.

Then, I am not sure, but quite sure, this ShortCode is broke as well:

[formidable id=22 postid="[wpv-post-id]"]

It can almost not be that the Same ShortCode does once expect "" and once not.
Hence I think here the ID attribute should use "" as well:

[formidable id="22" postid="[wpv-post-id]"]

After I made those adjustments, the issue was not solved.
That is definitely the JS kicking in a but too late, or a lag, if you want to call it so.
It may be due to this error:

Failed to load resource: the server responded with a status of 404 (Not Found)

It expects it under hidden link.

I tried this and deleted the plugin, regenerate the Loop so to use Toolset markup only, but I still see the lag.
It is even visible if you resize the browser window.

It is as well present with another theme.
At this point it is clear that it's due to <script src="hidden link"></script>
As soon you remove it, the issue is gone.

This is A) not the right way to introduce JS libraries to WordPress (you should enqueue it) and B) it may be unsolvable - that JS recalculates the sizes and positions on the grids and requires some time for it to build the output.

I assume, after Views returns the results, the time is very little to handle the reordering and resizing.
It may be possible to solve that by enqueuing the JS according this:
https://developer.wordpress.org/reference/functions/wp_enqueue_script/

Finally, the issue was solved locally as soon I did not use the code in the JS Front End events:

jQuery( document ).on( 'js_event_wpv_pagination_completed', function( event, data ) {
runmasonry();
});

(I call the script as you do in the script tags in this case, but do not add this JS to the events)

That as well solved the issue.

Can you give it a try?

#1069314

Beda, sorry my code skill does not really help me understand all your reviews here, can you provide a screenshot of your fix? Thanks.

#1070038

There are no screenshots, which I can show you, as the issue is something that you need to remove/change in the existing site.

Please follow the steps I outlined, summarized below:

1. This ShortCode is broken:
[vcex_image_banner heading="[wpv-post-title]" caption="[types field="brand"][/types]" image="[types field="featuredimage"][/types]" content_align="center"]

==> It is in the View that has the issue, in it's Loop Item template.
==> You will see immediately what I mean when you look at the syntax highlight and correct the apostrophes.
The red highlights will disappear as soon you fixed the ShortCode as I show here:
https://toolset.com/forums/topic/how-to-make-post-display-like-essential-grid-layout/#post-1069210

2. This, [formidable id=22 postid="[wpv-post-id]"], is not a Toolset ShortCode so I cannot know how it works, but all ShortCodes usually do put their values in apostrophes so that should be a mistake, probably, as illustrated in my previous reply, probably that should be id="22" and not id=22

This does however NOT solve the issue!

3. The issue locally was only solved, after I had disabled all non-toolset software, and removed the JS Code from the Filter editor JS Section which you had added to re-fire the Masonry Grid:

jQuery( document ).on( 'js_event_wpv_pagination_completed', function( event, data ) {
runmasonry();
});

In this case I can still use the masonry and it works fine.

You can start - if you want - by just removing that JS, maybe it is already enough to solve the issue, however, if not, I would suggest to follow my above steps

#1071506

I'm sorry Beda, after I follow the steps, the grid is still messed up, I disabled most of the plugins other than WPbakery and Formidable form which are essential, and removing the JS from Filter editor does not solve the issue, can I provide you an admin account for you to take a look? Thank you for your patience with me.

Best,

Tye

#1073413

Yes, absolutely.

Would it be possible to migrate this to a staging site first?
The thing is, it may require to edit something and/or remove things that would break the live site temporarily

That would not be nice

I activated a private reply