I upgraded an existing site (a dev version). The header is set to sticky. When I scroll the class .x-bar-fixed is added to the .x-bar.
I use this class to add custom css to the bar. The bar is also set to shrink.
When you scroll back to the top the .x-bar-fixed class is not removed. This means the bar is still smaller than it should be and the custom css does not work.
If I click on a menu item or similar then everything jumps as the class is then removed.
Howdy, @urchindesign!
I have tested this locally and the x-bar-fixed class appears to be added / removed as expected as I scroll down the page and then get back to the top in both the live preview and the frontend.
Do you happen to have any custom JavaScript on your site, plugins, or other modifications via a child theme that could be conflicting with this potentially? I assume since it’s a dev site you are not allowed to provide login credentials at least if it’s local.
I can provide credentials. Just a back up of my site from some time back. It is a site I upgraded and there seem to be a ton of issues besides this.
I did have Litespeed Cache plugin but have disabled it and will test again. Will also deactivate everything except pro and see what happens.
I’ve deactivated all plugins and removed all custom code from my child theme for testing. I’ve since turned on most of the plugins but you can turn them off if you like.
This site is pretty much something you can mess around with as much as you like. I’ve added credentials for you.
The site is quite old so many of the rows are still “Classic Rows” etc. so perhaps this is what is causing some issues??
It is the same site I’ve used all day with the Beta installed and as per all my posts today.
Thanks! I’ve got this noted down as something to look into as time permits.
@urchindesign, when we tried logging into your install earlier we received the following message:
VERIFICATION REQUIRED: Additional verification is required for login. Please check the email address associated with the account for a verification link.
Is that something you could potentially disable temporarily on your end at least for our login so we can get in there? I don’t think we saw anything come through on our end after seeing that.
Thank you!
I’ve turned off the reCAPTCHA in WordFence. Sorry for the troubles. You should be able to get in now. Also if you can provide an email address then I can update the user to an email address you have access to.
@urchindesign, if you could just leave off reCAPTCHA for any environments that we might have to get into for a time, that’d be great. Could be different people logging in depending on the nature of the task, so that’s the cleanest if at all possible, thank you for doing that!
I have deleted it completely and will leave it off.
Thank you!
I think I’ve figured this one out. It is still not working in Beta 2.
My header has a “Trigger Selector”. With the “Trigger Offset” set 0. If I remove the “Trigger Selector” and use a “Trigger Offset” instead, then the headers work as they did it “Pro 5”.
As such I presume it has something to do with the “Trigger Selector” not being picked for some reason.
@urchindesign, thanks for the context here. I have noted this down, but it may not be something we fully get to in this cycle. We have some other documented items relating to sticky bars as a whole, and it might need to be given a more thorough cycle that runs through those things in a more focused fashion. Thank you.