Your CSS code has this:
html {
margin-top: 0 !important;
}
When logged in, this causes the admin bar to overlap the site and this usually means navigation is blocked. There are a number of better ways to handle this. Personally, I think the best thing is to not override the default margin-top for the html tag at all. Another option is something like this:
/* SET DEFAULT OFFSET 0 SO WE CAN POSITION OUR OVERLAYS */
body:not(.admin-bar) {
--wp-admin--admin-bar--height: 0;
}
html {
margin-top: var(--wp-admin--admin-bar--height) !important;
}
Above code is untested with AnimatePress but I have used it on other sites and it’s worked well.
]]>Issue: when the back button is used to navigate back to a page, the overlay and loader persist and the user must reload the page to use it.
Solution: hide the overlay and loader when the back button has been used to return to a page.
Workaround: here’s a JS snippet that you can implement that simply hides the transition when the page has been loaded from the back/forward button cache. I experimented with using the animation hide the overlay and loader, but this is faster and I don’t think people will complain much since hitting “back” is usually a nearly instantaeous thing.
window.addEventListener('pageshow', (event) => {
if (!event.persisted) return;
console.log('Page loaded from bfcache (back/forward button detected)');
// Check animatepress status
if (!ANIMATEPRESSDATA.options.isActive) {
return null;
}
// Get elements transitions
const body = document.querySelector("body");
const overlayElt = document.getElementById("animatepress-overlay");
const loaderElt = document.getElementById("animatepress-loader");
// Global functions
const hideOverlay = (time = 0) => {
body.style.overflow = "hidden";
setTimeout(() => {
body.style.overflow = "initial";
overlayElt.style.opacity = 0;
overlayElt.style.visibility = "hidden";
}, time);
};
//Loaders functions
const hideLoader = (time) => {
setTimeout(() => {
loaderElt.style.opacity = 0;
}, time);
};
hideOverlay();
hideLoader();
});
]]>
I hold the CTRL and SHIFT keys a lot when navigating sites to pop a new tab or window. I would like to suggest that when these keys are pressed that your plugin ignores the click. This would allow for normal navigation to have the effects and for new tabs and windows to be opened ??
Here is a script I use for something else which handles this behavior:
<script>
document.addEventListener('click', function(event) {
// Bail if the click originated from an actual link inside the hot cover
if (event.target.closest('a')) return;
// Find the closest ancestor with both 'wp-block-cover' and 'hot' classes
const hotCover = event.target.closest('.wp-block-cover.hot');
if (hotCover) {
const link = hotCover.querySelector('a');
if (link && link.href) {
// Check for modifier keys (CTRL or CMD for opening in a new tab)
if (event.ctrlKey || event.metaKey) {
window.open(link.href, '_blank');
} else {
link.click();
}
}
}
});
</script>
Thanks!
]]>I would like to suggest that admin bar links be excluded from being targeted for transitions since it adds a small delay in switching to edit mode and performing other operations. Or maybe make it an option in the plugin ??
Thanks!
]]>FANTASTIC PLUGIN!
I have some links on my site which open a fullscreen popup form and they have progressive fallback in case the user does not have javascript. They might look like
<a href="/contact/#fsconsultation">Get a consultation</a>
The #fsconsultation
bit is what tells the page to launch the popup with id fsconsultation
When your plugin is installed and activated, these links ignore my script to launch the popup and instead navigate to /contact/ on the site using the transition. I would like to be able to list selectors for exclusion in your plugin so my script can execute.
]]>