[Resolved] Deactivating additional div since latest WP Views version (1.11)

[Author]

Posts

[manuelE]

Hi!

I realized that Views is creating an additional div around the actual view since the latest version (1.11).

I opened up a support thread regarding that already:
https://toolset.com/forums/topic/views-adds-additional-div-which-is-causing-a-delay-in-responsive-behaviour/

Shane explains that this div was added because of the new features that were included in views 1.11 in order to support the infinite scrolling amongst some of the other new features.

But this is causing a delay of the responsive behaviour in views:
When the page loads initially it works fine but after resizing or waiting a little bit the views plugin adds a "style:width=xxx px"-attribute which is updating with a delay after resizing.

In the support thread with Shane it turned out that it´s not possible to deactivate that behaviour (so I went back to the previous version for now).

So my feature-request is:
Having an option to deactivate this new DIV if I don´t need it. It was so nice and clean that views just showed exactly the HTML I wrote in the view and nothing else.

Thanks in advance!!!

Cheers,
Manuel

[Beda]

Thank you for contacting us here in the Support Forum

The new HTML that is wrapped around the Loop Output should only have a negative effect on sites using unintentional Data generated with Views, such as JSON, to populate other Fields or even 3rd Party Code.

This is and was never the intended behavior of Views, and the Custom Code Shane provided is the only "workaround" to get a "data only" Loop result.

All features of Views will not apply when that code is used.

Now, the issue you mention is worrying me, as this additional HTML is not meant to break responsiveness of the output.

I need to analyze this and if your current code is following best practices and intentions of Views, I need to report it.

What I do not full understand is:

"This is causing a delay of the responsive behaviour of the view. If the page loads initially it works fine but after resizing or waiting a little bit the views plugin seems to add a "style:width=xxx px"-attribut which is the reason for my problem."

With "responsiveness" you mean, responsive in the mean of mobile ready or performance in site loading?

Ina you describe what is happening exactly, provide me the code you use in the Loop and what you expect?

Then I can analyze and report.

To answer your feature request:
We are already considering a feature suggstion that consists on a way to select a View, select a Content Template, and then get the raw results of the Content Template applied to each element of the View results. It would be the most closer thing to a clean View data source engine, although it would still not be completely safe for JSON objects as example.

So I will add your vote there.

But for proper troubleshooting I must be sure, about what the issue is exactly.

As mentioned, responsiveness should not be affected in any case.

Please could you provide me the additional Infos?

Thank you for your patience.

[manuelE]

Hi Beda,

many thanks for that detailed response! 🙂

The project I discussed with Shane is now running on the previous Views-version, so I can´t show it to you there. Because of that I just updated to Views 1.11. in another project on which I´m working on at the moment. Now it show´s the same "responsive delay"-behaviour.

Please see:
hidden link
(the event-teaser boxes are a view)

Description of my problem:
At first it works fine (try resizing the window just after loading initially)
After resizing once the inline-css "style="width: XXXpx;" attribute appears in the new views-div.
When resizing again this width-number is re-calculated with a delay so the views-container is adjusting to the new width later than the parent container.
(the screenshot attached shows the inline-css)

What I would need:
The div should simply keep the default 100% width (I´m not really getting why views needs to add this inline-css.)

Can you see my problem?

Thanks again for your help!!!
Manuel

(you Toolset-support guys are just great by the way! :-))

[Beda]

I believe to have understood the issue here and this is IMHO not what we can define as "expected", not even if we support new features with this default HTML.

Responsiveness is one of our basics and as I see on the site, responsiveness is simply broken after resize-down, resize-up, and resize-down again.

After #3, it's simply not resizing and therefore not responsive.

But to confirm this is View (generic and basic) output I need to replicate it.

The Problem is, locally I can replicate it only 1/2.
That means, I see a delay in resizing, but not a full stop of resizing.
It "holds" around .5 s and then it resizes.

While this is not agreeable and surely must be analized, it is not the exact same behavior as on your end.

A question:

1. would it be possible to provide temporary access (WP-Admin and FTP) to your site
- preferably to a test site where the problem has been replicated if possible -
in order to be of better help and check if some configurations might need to be changed

Your next answer will be private which means only you and I have access to it.

❌ Please backup your database and website ❌

✙ Please add the Links to the View Edit Screen, the Page/Post where you insert the View form and the corresponding Front End Page/Screen

2. Or could you perhaps send me a Exported View (Views > Import / export) so I can try to replicate this locally?

It is sure, it must be analyzed.
Style is added, and while on my end it is resizing (style width from 305 to 848 px in less then .5 s and back), on your end this seems to "hang"

A doubt - do you use Cache plugins, or cached View?

Please could you provide me the additional Infos?

Thank you for your patience.

[Beda]

Thanks for the Details

I think I was able to present the 2nd Tier with a valid step by step description.

Nonetheless, please keep your access details running so in case we need, we can login.

What I must observe is that you have some Toolset (and other) plugins outdated, and i suggest to update them.

I don't say that's the case of the issue, as I can replicate it.

I just always must suggest to update, so to grant best workflow and debugging processes.

Please expect my informations here in the forum.

Thank you for your patience.

[manuelE]

Hi Beda,

great – thanks for keeping me posted!

Bye,
Manuel

[Beda]

I apologize the delay here

I just got word from the DEV Team in regard.

On Views 1.10, we resized the Views output every time a resize event was fired.

It meant than when manually resizing the browser, that event got fired thousand of times.

On Views 1.11, we added a debounce method, which means that we added a tolerance, and when a resize event is fired, we delay the execution of the callback until that tolerance time is completed, and if another resize event is fired on the meantime, restarting the tolerance counter.

We can lower that tolerance, but is has actual performance reasons.

In natural landscape-to-portrait switching, this should have no visual effect.

The DEV team will review that tolerance and maybe even add an animation effect so the change in width is not so raw.

Please let me know if you need further infos about this and do not hesitate to open a new thread if other issues or problems arise

Thank you for your patience.

[Beda]

In Views 1.11, the tolerance before firing the resize callback was 1000 miliseconds, a whole second.

Our DEV Team lowered it to 100 miliseconds and added a filter so you can adjust it by hand.

It will be shipped in Views 1.12

Please let me know if you client need a patch with the lowered tolerance hardcoded.

I can ask the DEV to provide it and ship it to you.

For that, I would need to request temporary access (WP-Admin and FTP) to your site
- preferably to a test site where the problem has been replicated if possible -
in order to Upload the Plugin to your FTP.

Your next answer will be private which means only you and I have access to it.

❌ Please backup your database and website ❌

Thank you for your patience.

[Beda]

I apologize the delay here

On 80% of the Views, there was indeed a wrapping div.

Used on table layouts, when having pagination or parametric search as example.

So in those cases, we did apply "style:width" changes when resizing.

You could not see them because there was no tolerance: we calculated the width as the resizing was being done.
This is smoother, but extremely bad for performance: the browser needs to calculate the new width constantly while calculating a ton of other things due to, well, the resizing.

We had this mechanism because pagination, and other AJAX actions, do need the wrapper dimensions to load the next page, for example.
So when resizing it kept the width calculated before the resizing.

Imagine a slider that, when switching from landscape to portrait, overflows beyond the view and you can not adjust it.
So as long as a wrapper is needed, the mechanism to make it responsive is mandatory.
It was slow, anyway, waiting for a whole second since when the resize ended to adjust the dimensions.

Now, on other simpler Views, like lists or unformatted without pagination or search, there was no wrapping div, so we did not calculate any width to apply to nothing.
It was up to you, generating the output, to make things responsive.
As there was no wrapper, it all depended on the outter structure outside the View.

From now on, the wrapping div is mandatory, which means that we are also making it mandatorily responsive.

In regard to your latest Questions:

1. Any ways, now it´s there, "that div" 🙂
And I´m afraid there´s no way to get rid of it again, right?

Correct.
We are planning a Type of Views that will provide a "raw" loop output but that is more intended for using Views as a "Data provider" and not for rendering things with it.
Also, you can use this Code very carefully (read the warnings in the thread)
https://toolset.com/forums/topic/views-result-array-as-shortcode-parameter/page/2/#post-344768

2. For now, I´m fine with Views 1.10 and will wait for 1.12 – so there´s no need for a pre-hardcoded version.

Thank you for your patience and understanding.
I appreciate this very much, and if you need such a hardcoded temporary solution, don't hesitate to ask me here.

Please also do not hesitate to open a new thread if other issues or problems arise

Thank you for your patience.

[manuelE]

Many thanks again!