[Escalated to 2nd Tier] View Pagination Elements do move with the paginated content instead of sticking

[Author]

Posts

[smileBeda]

I am trying to:
Build a simple slider

Link to a page where the issue can be seen:
None needed, this is a very old issue

I expected to see:
Well, in my opinion and looking at tens of slider examples built with other tools a slider, or generally a paginated loop, will MOVE its contents but NEVER MOVE its pagination controls when the loop is moving to the next page.

However with toolset, the pagination elements do move together with the content, making a real slider close to impossible.

Try these steps in either Blocks or Views.

1. Create a few posts
2. Create a view that loops those posts
3. Paginate it by one
4. Choose either vertical or horizontal scroll instead of fade effect
5. Add pagination controls of any kind driven by AJAX on user input
6. Observe on the front end and see that when pressing next page the actual pagination slides together with the "loop item", as if it would be part of the post/

Is this not utterly ugly and simply wrong?
Unless I miss a crucial thing, there is not even a way to resolve this in classic view, because even if adding the pagination items OUTSIDE the [wpv-items-found] in a classic view loop editor (which is perfectly possible and supported by the GUI), these pagination items still slide #together# with the content, instead of staying in place and letting only the loop slide.

I find it weird and it is certainly not what people expect of a slider/paginated loop.
Why would users want a pagination control *disappear and reappear* together with the slider content, even worse, observing them move along with the paginated loop?
The pagination items must be static/fixed in position and not move.
Just like it is when you insert the pagination in the SEARCH area, where the result will be a moving loop when paginated and a fix/static pagination item which will NOT move along the paginated loop.

But, of course if you place the pagination elements inside the search editor/area, you cannot have a nice layout of pagination controls to left/right/up/under your content but only the whole chunk of paginations BEFORE or AFTER your loop, not wrapping the loop, which is extremely unlikely to have in a advanced site.

I hope the issue is clear. I am aware a fix won't come fas for this, it is how Views works since ages, but its wrong and stops developers like me to even consider Toolset to create sliders, as a matter of facts, specially when you do not want to charge the end consumer with a bulk of CSS/JS used to simply position 2 pagination controls.

We'd all appreciate a fix for this, or if I am missing a crucial detail.... please do not hesitate to correct me 🙂

[Jamal Supporter Languages: English (English ) French (Français ) Timezone: Africa/Casablanca (GMT+00:00)]

Hello Beda and thank you for contacting the Toolset support.

This issue has already been reported for Block sliders, I'll inform our developers that this happens to the legacy views too.

I hope that the following workaround will be a viable solution for you. https://toolset.com/forums/topic/split-how-to-stop-pagination-controls-from-scrolling-with-the-results/#post-1648521

Let us know your feedback 🙂

[smileBeda]

Hi Jamal, nice to talk with you...
The workaround makes it better, but I think there are some issues still.

Since there may be many views on a page one would need to address each views loop separately.
Otherwise, when you update the pagination of one view all other views also would get the trigger since having the same HTML classes.

Now, there would indeed be a way to address JS to only the view with ID equal to view_unique_id object property of data (as delivered by js_event_wpv_pagination_completed hook.
But that object property has issues.
It cost of times throws a undefined data error.

This is an older bug too, I recall it being around a while.
To trigger it, instead of the workarounds JS use this JS:

jQuery( document ).on( 'js_event_wpv_pagination_completed ready', function( event, data ) {
  	console.log(data);
    updatePagination();
});

Reload the page with the View.
There is already a undefined in the console logged, which should never happen in the js_event_wpv_pagination_completed hook as that is supposed to trigger only once AJAX paginated.

Then if you actually do trigger pagination you'll see this logged:

{view_unique_id: 54183, effect: "slideh", speed: 500, layout: n.fn.init(1), filter: n.fn.init(1)}

Now that seems to be OK, but if you want to use that in our JS, you will need to get the view_unique_id property. Agreed?

Let's try

jQuery( document ).on( 'js_event_wpv_pagination_completed ready', function( event, data ) {
  console.log(data.view_unique_id);
    updatePagination();
});

(Please let me know if my JS has a flaw, but data.view_unique_id or data['view_unique_id'] should really give us the object's property, if I am not totally wrong?)

Reload page
Due to thejs_event_wpv_pagination_completed being fired anyway even if we did not AJAX, now you get a fatal JS error Uncaught TypeError: Cannot read property 'view_unique_id' of undefined, which makes the pagination disappear, so you can't even trigger it anymore.

Hence, it is impossible to check if you are on a current view with that hook, and hence, the hook destroys all other views on page and the only way to solve that, is hardcoding unique Classes for each View on page with pagination.

For now, it's a workaround, but it's also a reason why one could not really "sell" this solution to a potential customer, as it needs maintenance and eventually is wrong. Just think of how many printed JS styles the page source for example will produce with this solution, which is also not ideal.

Additionally even hardcoding the IDs to target and having unique JS function names to trigger, if you have several views on page, triggering the AJAX in one view does trigger it on the other views too, making the pagination disappear. Somehow, it is all quite unstable.

Being this solution not applicable to Blocks at all, I am a bit at a loss to find other things in Views/Blocks that are "unique" and cannot be done in other, more stable plugins.

I mean, currently we clearly can't paginate in a modern way, there is additionally a bug that removes query filters from block views once you save the view (please let me know if you need a ticket about this but I am quite sure I personally already reported that back in time to your internal tracker 😉 )...
Basically I cannot filter, or paginate a Blocks View or View at all, without severe workarounds or compromises and even so, it is still not perfect

Pleas understand, I am not trying to rant, I just see that this a basic feature that makes Toolset stand out amongst other plugins:
The creation of a dynamic loop.

However, if it's broken, why would we use it?
And that is unfortunately one of the only features left unique to Toolset, because to be honest, (hate) Elementor is doing many of the things better meanwhile (Like forms, templating, even loops and queries).

You know that I bleed and dream and fan for Toolset and Toolset only, but this is getting somehow very hard to do 🙂

Are these issues handled with some priority?
I think these things are the ,strength of Toolset! It is sad they are not properly working out of the box.

Summary of Addon issues
- js_event_wpv_pagination_completed fires even if AJAX is not triggered
- data.view_unique_id throws errors
- Query filters in Blocks Views are deleted from the GUI after save + reload

[smileBeda]

Or, another example that is quite showstopping

Have a grid, with two columns.
Put a Single Field to the left column, and one to the right column
Then try to align vertically both fields middled.

It's a thing of impossibility unless you know that for (unknown reasons) Toolset adds a default margin bottom to the (automatically added by toolset) "tb-field" class of such single fields.
If we have margin bottom, aligning vertically is never going to work.
So we need to (why??) go to the single field block, add "0px" margin bottom to it, then center or else align the Grid Cell contents with the grid cell align vertically settings.

IMO, expected is, I add a grid, I add a block in a cell of a grid and press "align middle" on the grid cell settings.
Nothing else should be needed.

Why is toolset adding default styles like margins to a simple single field block?
It makes no sense and is wasting everyone hours to even figure out what's going on.

Look at my screenshots, where I show precisely what happens in a black bordered grid that has vertically middle aligned single fields in it.
The default border bottom of 0.76em is the cause, and IMO should simply be removed.

But now you can't, because thousands of sites already were built with 0.76em margin bottom since it is Toolset's default, so thousands of users applied margin bottom 0 to their fields, and if now Toolset changes the rule, all will be screwed again 🙂

Again, I'm not complaining - just trying to make you see how small issues can be simple showstoppers.

[smileBeda]

I'm sorry! The js_event_wpv_pagination_completed does not fire when the page is loaded, that was my mistake since the function was/is hooked to "ready" event as well.
Ignore that part 🙂

I'm just sharing the solution for anyone having several Ajax paginated views on the same page running into this issue, you'll need to apply Waqar's workaround but create unique HTML classes in each single of the views. Then address each single View with adequate JS like the below example. Make sure to check on the view unique ID, or your pagination will disappear on all views, when you trigger it on a single instance.

HTML example of loop (54197 is the ID of the View, it needs to be unique for each view)

<div class="row justify-content-center">
  <div class="col-2 justify-content-center shadow-pagination-left-54197">
  </div>
  </div>
  <div class="row">
  <div class="col align-self-center justify-content-center">
[wpv-layout-start]
    <div class="original-pagination-left-54197">[wpv-pager-prev-page force="true"]LEFT[/wpv-pager-prev-page]</div>
	[wpv-items-found]
	<!-- wpv-loop-start -->
	<wpv-loop>
		[wpv-post-body view_template="loop-item"]
	</wpv-loop>
	<!-- wpv-loop-end -->
	[/wpv-items-found]
	[wpv-no-items-found]
		<strong>[wpml-string context="wpv-views"]No items found[/wpml-string]</strong>
	[/wpv-no-items-found]
    <div class="original-pagination-right-54197">[wpv-pager-next-page force="true"]RIGHT[/wpv-pager-next-page]</div>
[wpv-layout-end]
    </div>
    </div>
	<div class="row justify-content-center">
  <div class="col-2 justify-content-center shadow-pagination-right-54197">
    
    </div>
  </div>

Then the JS:

// function to copy pagination's content from one div to another
function updatePaginationUniqueIdentifier() {
    jQuery('.shadow-pagination-left-54197').html('');
    jQuery('.original-pagination-left-54197').contents().appendTo('.shadow-pagination-left-54197');
  	jQuery('.shadow-pagination-right-54197').html('');
    jQuery('.original-pagination-right-54197').contents().appendTo('.shadow-pagination-right-54197')
}
 
jQuery( document ).on( 'ready', function() {
    updatePaginationUniqueIdentifier();
});
jQuery( document ).on( 'js_event_wpv_pagination_completed', function( event, data ) {
  if(data.view_unique_id == 54197){
    updatePaginationUniqueIdentifier();
  }
});

CSS

div.original-pagination-left-54197, div.original-pagination-right-54197 {
display: none;
}

To above JS and CSS, change UniqueIdentifier with a unique suffix for each view.
Change 54197 to the View ID you are addressing (or suffix used in HTML if different)
Make sure to check on the right View ID for data.view_unique_id, and separate the ready and js_event_wpv_pagination_completed events.

Then it works.

[Jamal Supporter Languages: English (English ) French (Français ) Timezone: Africa/Casablanca (GMT+00:00)]

Hello Beda and thank you! My apologies for the late reply, but I do not work on Sundays and Mondays.

You are right, Waqar's workaround is not optimized for pages that contain multiple views. Your workaround, instead, is optimized for that case and it is clear enough to be used by any other user.

Regarding the default style on the "tb-field" class, I can't tell why this was implemented that way. But, that can easily be overwritten by the (child)theme styles, or by a custom CSS code(if you are using content templates or views)

We have released today a new version, for only a portion of our users, you can force an updates check on the updates page.
I'll let you test it and let me know if there is anything else you want me to escalate.

[smileBeda]

Let’s keep the pagination issue on this ticket.

Thanks!

[Jamal Supporter Languages: English (English ) French (Français ) Timezone: Africa/Casablanca (GMT+00:00)]

The pagination issue is already escalated to our developers but we don't have an ETA for when it will be released.

As of now, I'll have to kindly ask you to mark this ticket as resolved. You can check the changelog to confirm if the issue was resolved when a new version of the plugins is released.
- https://toolset.com/download/toolset-blocks/#changelog
- https://toolset.com/download/toolset-views/#changelog

All the best!

[smileBeda]

Unless there is another open Ticket I can follow I am not aware of, I would like to keep this escalated so I get notified when it is fixed, because I will have to remove the workaround and implement it properly once fixed in the site.

Thanks!

[Jamal Supporter Languages: English (English ) French (Français ) Timezone: Africa/Casablanca (GMT+00:00)]

Sure. Let's set the ticket as "Fixed in next release" and we'll check it again when a new release is published.

I'll keep you updated.

[smileBeda]

I'm bumping this because It was not fixed in the "Next Release", instead it is still happening. Especially in the Blocks Editor this is actually a issue, it may not be that big of an issue in legacy, I'd even understand if you wouldn't fix it there.

However, I saw also that interestingly all Videos and Sample sites do not have this issue, meaning, all videos and sample sites do not follow the "default" setup of Blocks, but we never see that in the videos or how to articles, which I consider bad. It misleads the user.

Can you give me a heads up as of what the plans are about this issue?

Remember for many users it is important to have the things that are advertised working as they are advertised and prefer them fixed rather than getting new features. At least, this is the case for all my clients using Toolset.

Thanks!

[Nigel Supporter Languages: English (English ) Spanish (Español ) Timezone: Europe/London (GMT+01:00)]

Hi Beda, I spotted your reply, Jamal's "weekend" is Weds/Thurs.

I'm not sure why this is marked as Fixed in Next Release, we are talking about the pagination controls sliding with the content, right?

That hasn't been worked on yet. We are nearing the end of the current dev cycle, mostly focused on WC, the next cycle that begins shortly is focused on improving Views searches—new filters and more control over styling etc.—and then the following one is revisiting the block editor for Views, to decouple it from pages so they can be edited independently, allowing nested Views etc. That is when this issue is slated to be worked on, so we are looking at the second half of the year I'm afraid...

[smileBeda]

Thanks Nigel, it confirms what I suspected.

Perhaps you can just remind Jamal to put the ticket in escalated state once he's back so I'm not triggered to ask again 😛

Second half of the year is going to be soon enough, it's ok for me, of course one would wish for faster, but I know how it is... we can't have it all at once.