I'm back but with a real, proper problem this time. So, I made a contact page based on the "blank" default template and I have one main row in the page that I set to full height.
Problem : even if I hide (with display: none) the footer in CSS, for some reason, when loading the page, the vc row minimum height is 85% and only AFTER I resize the window, it instantly changes to 100%. But when I DON'T hide the footer in CSS, the vc row height is correctly at 100%, but since the footer isn't hidden there's still some left over space at the bottom. I just want proper main div at 100% without any footer content in my page but there's always something that seems to get through in the footer section resulting in unwanted space, and therefore unwanted calculation in the vc row height.
I've tested this on another page template, and it seems the vc height is correctly displayed, but on the default page template there's some vc height math that's not working properly, or wasn't taken into account.
I made videos which should make it pretty obvious and self-explanatory (sorry about the music, it recorded what I was listening to while working) :
So, I'll reply to my own post since I figured out a solution on my own :
turns out all I needed was to redeclare the "vc_row-o-full-height" class in the custom CSS with forced "min-height: 100vh !important" to match the setting of my row in WPBakery.
To be honest, I don't really understand why the setting isn't correctly taken into account in the first place, since everything otherwise works normally with AJAX (contrary to what the documentation indicates ?).
This may not be necessary if you are using the grenada wpbakery child theme.
Ajax page transitions will load the target page content container within the original page. Since the target page is not loaded normally, the <head> and <body> elements will stay the same. This is how is possible to have seamless transitions.
Since a lot of plugins are using javascript initialisation in the head (or the footer) of the page they don't get called in the target page. WpBakery injects most of the styles and initialisations in header and footer
The solution we found is to put all the extra inits in ajaxSuccess event handler as you can see in the child theme we provide in main archive (I attach it here for your convenience, childscript.js file)
Thank you for the reply. I don't quite understand what you mean : I am already using the child theme with your custom ajax loading and script handling solution, so that doesn't change my problem (and my "fix") in the first place.
As you probably noticed in the child theme's childscript.js file we call vc_js() function which is part of the WPBakery API - the only problem we have is:
- we don't how much functionality it covers
- we don't know if there are other API functions out there that need to be called to ensure everything is initialised
So vc_row-o-full-height feature may fall in the second category
Hello,
I'm back but with a real, proper problem this time. So, I made a contact page based on the "blank" default template and I have one main row in the page that I set to full height.
Problem : even if I hide (with display: none) the footer in CSS, for some reason, when loading the page, the vc row minimum height is 85% and only AFTER I resize the window, it instantly changes to 100%. But when I DON'T hide the footer in CSS, the vc row height is correctly at 100%, but since the footer isn't hidden there's still some left over space at the bottom. I just want proper main div at 100% without any footer content in my page but there's always something that seems to get through in the footer section resulting in unwanted space, and therefore unwanted calculation in the vc row height.
I've tested this on another page template, and it seems the vc height is correctly displayed, but on the default page template there's some vc height math that's not working properly, or wasn't taken into account.
I made videos which should make it pretty obvious and self-explanatory (sorry about the music, it recorded what I was listening to while working) :
https://streamable.com/9j285b
https://streamable.com/8hs3m3
So, I'll reply to my own post since I figured out a solution on my own :
turns out all I needed was to redeclare the "vc_row-o-full-height" class in the custom CSS with forced "min-height: 100vh !important" to match the setting of my row in WPBakery.
To be honest, I don't really understand why the setting isn't correctly taken into account in the first place, since everything otherwise works normally with AJAX (contrary to what the documentation indicates ?).
Maybe it's something you could fix on your side ?
Hello Antoine,
This may not be necessary if you are using the grenada wpbakery child theme.
Ajax page transitions will load the target page content container within the original page. Since the target page is not loaded normally, the <head> and <body> elements will stay the same. This is how is possible to have seamless transitions.
Since a lot of plugins are using javascript initialisation in the head (or the footer) of the page they don't get called in the target page. WpBakery injects most of the styles and initialisations in header and footer
The solution we found is to put all the extra inits in ajaxSuccess event handler as you can see in the child theme we provide in main archive (I attach it here for your convenience, childscript.js file)
Thank you.
Clapat Support
https://www.clapat.com/
Review Envato Item Support Policy
Hello,
Thank you for the reply. I don't quite understand what you mean : I am already using the child theme with your custom ajax loading and script handling solution, so that doesn't change my problem (and my "fix") in the first place.
Am I missing something ?
Hi Antoine
As you probably noticed in the child theme's childscript.js file we call vc_js() function which is part of the WPBakery API - the only problem we have is:
- we don't how much functionality it covers
- we don't know if there are other API functions out there that need to be called to ensure everything is initialised
So vc_row-o-full-height feature may fall in the second category
Thank you.
Clapat Support
https://www.clapat.com/
Review Envato Item Support Policy
Ok, I'll just deal with it with the CSS "hack" and be good with it.
Thank you, ticket can be closed.