- What’s your URL? This is the easiest way for others to debug your issue
https://stout-bowman-associates-llc.ghost.io/ - What version of Ghost are you using?
Current version hosted by Ghost Pro - What configuration?
Using a modified Casper theme to add a sticky navigation bar to the top of every page - What browser?
Problem exhibited in Chrome and Firefox - What errors or information do you see in the console?
No errors - What steps could someone else take to reproduce the issue you’re having?
Visit the home page, the top menu bar sticks to the top of the browser window as the first 6 entries are scrolled (posts-per-page is set to 6 in package.json). It stays sticky when the next 6 entries are revealed by scrolling down. When further scrolling causes the next 6 (entries 13-15) to be shown, the top menu loses it stickiness and scrolls with the page. I suspect this is a function of infinitescroll.js, but I don’t know how to fix this. I am using Foundation for Sites to produce the menu bar, and it works fine on my non-Ghost site and just normal scrolling. Foundation allows for checking the menu position a variable number of times the window is scrolled, and I’ve set this to 0 so that is checks every time the window is scrolled, but it does not change the behavior at all. Changing the posts-per-page does not fix it, it just shows more or less posts, and the top menu starts scrolling after the third set is loaded.
@pvollmar on my Chrome Version 81.0.4025.0 (Official Build) dev (64-bit) on my Pixelbook (Chrome OS) the stickiness persists all the way to the bottom, the top menu never disappearing.
Also on both Chrome and Safari on my iPad mini sticky persists, menu remains appearing all the way down.
1 Like
OK, this is going to be one of those … well, I’ll not say on this forum. I tested on Ubuntu 16.04 Chrome and Firefox, and got the original failure mode. On Chrome, If I clear the cache after the top menu “unsticks” the problem is still there. If I scroll to the top of the page and reload it, the problem does not occur. If, after I’ve scrolled down more than the first two pages, and reload the page, the problem is back (in short I need to reload the page while it is at the top so that I don’t incur the problem). It has not failed on Firefox after I cleared its cache. It does not fail on Chrome on Windows 10, either. The kicker is that if fails on the new Edge, which is Chromium-based, the same way it does on Ubuntu Chrome. I guess I’ll have to hope no user with Chrome gets into that sequence of events. Fortunately, this is a low-use blog, so I’m probably OK, but it sure is frustrating. Thanks for your testing, I’d be curioius if you see the same fault pattern.
On Microsoft Edge 44.19546.1000.0 on my Winblows machine, I cannot get it to misbehave – the menu remains sticky, always appearing at the top no matter how far down I scroll.
I appreciate your persistence in testing. Here’s the scenario that produces the problem (for me, on both Ubuntu Chrome and Windows Edge): If the page is already up, be sure it is at the top -> clear cache -> reload the page -> scroll down past the 2nd load of post cards (at least 15, since posts-per-page is set at 6) -> reload the page -> scroll past the 2nd load again, and the top menu becomes unstuck. I suspect after the second load something is being set by infinitescroll.js that interferes with the Foundation javascript for sticking the menu at the top. I think that I will just go back to the original setting for Casper of 25 posts-per-page and implement a tag menu on the home page to filter the posts by topic.
I just tested this right now on Chrome, Firefox and Safari and it’s working fine. I scrolled down to the very bottom when no more posts would load and the header stuck to the top of the window all the way down. Shot in the dark but could it be a browser extension interfering with the code?
Well, the failure mode was scrolling past the first and second loading of additional posts, and then reloading the page, whereupon the top menu would become unstuck after the third loading of additional posts. However, the issue is moot now, as Casper 3.0.6 has a similar menu that does not exhibit the issue on my systems, so I am re-coding everything from that base (old one was Casper 2.10.2) and not using Foundation for the top menu, just re-styling the Casper internal menu to match my requirements. In fact, if you tested it today, you are probably seeing the Casper menu (mine that failed was black text on a white background, while the Casper menu is white text on a black background). Thanks for the help, though. Hopefully this is now fixed.
1 Like