blakmarkit

@markuipress sure!

In this case, I’m using a snippets plugin to load the JS, and I have conditions set to only load this on the Live Traffic page, inline in the admin footer. Not positive if this is the best way to do it, but it works for me.

var observer;
var lastContainer = null; // Store the last detected scroll container
var loadingListings = false; // Flag to track if a request is in progress

function attachScrollEvent() {
    var newScrollable = jQuery("#uip-id-of-the-scrollable-container");

    // Prevent re-attaching if it's the same container
    if (newScrollable.length && newScrollable[0] !== lastContainer) {
        lastContainer = newScrollable[0]; // Update last container

        console.log("New scroll container detected:", newScrollable);

        newScrollable.off("scroll").on("scroll", function () {
            var container = jQuery(this);
            var containerHeight = container.outerHeight();
            var containerScrollTop = container.scrollTop();
            var containerScrollBottom = containerScrollTop + containerHeight;
            var scrollThreshold = container[0].scrollHeight - containerHeight;

            // Add a slight buffer to trigger before exactly reaching the bottom
            var buffer = 50; // Adjust as needed

            // If no request is in progress and we're near the bottom, trigger the load
            if (!loadingListings && containerScrollBottom + buffer >= scrollThreshold) {
                console.log("Infinite scroll triggered!");
                loadingListings = true; // Set flag to true to prevent multiple requests

                WFAD.wfLiveTraffic.loadNextListings(function () {
                    console.log("Next listings loaded.");
                    WFAD.reverseLookupIPs();
                    WFAD.avatarLookup();

                    // Reset the loading flag after the request completes
                    loadingListings = false;
                });
            }
        });
    }
}

// Debounce function to avoid excessive calls
function debounce(func, delay) {
    var timer;
    return function () {
        clearTimeout(timer);
        timer = setTimeout(func, delay);
    };
}

// Observe changes and attach the scroll event
observer = new MutationObserver(debounce(attachScrollEvent, 500));
observer.observe(document.body, { childList: true, subtree: true });

// Initial attachment in case the container already exists
attachScrollEvent();

@markuipress So I did a lot of work to try to untangle what was happening. I made enough tweaks between the toolbar template, the header template, and the page content that I believe I’ve got it all working the way I want, again, but I can’t say for certain if this is a case of user error or if there’s still something else going on with the frontend toolbar. It may be that my previous approach worked correctly when it shouldn’t have out of sheer luck, and the update did things the “right” way and suddenly my incorrect approach stopped working? It’s worth checking if there are any issues with the sample templates in the editor’s library with the plugin’s rewrite to remove iframes, as those are the ones I’m usually going to be using as a baseline for customizing rather than building from scratch.

I’ll close this one out for now.

@markuipress yeah, I’ve tried messing around with different combinations of positioning on the various elements to work around the issue (including modifying the frontend toolbar template), but there isn’t consistency between how they behave with and without a frontend toolbar and even with the default WP bar. Nothing I’ve tried so far has worked for getting back to the pre-3.5 functionality. 3.5.01 might have worked ok with the toolbar template, but I can’t remember if there might have still been a few issues. I wasn’t using a custom toolbar template, previously—just the default WP toolbar.

Structure is like:
body
header
main
footer
/body

header is fixed/sticky
main may contain a secondary sticky header
main may contain a section with a sticky header for that section
main may contain a sticky table of contents element

body has a min-height: 100vh to push the footer to the bottom and force a scrollbar so that there aren’t layout shifts if the content is shorter than the viewport.

This issue appears to be worse than before with 3.5.05. This seems to be happening with uipress enabled and both while using a Frontend toolbar template and using the default WP toolbar.

This appears to be mostly fixed in 3.5.05. One particularly odd thing—in the Gutenberg editor (non-fullscreen), if I have the editor’s Settings sidebar open, the Options dropdown loads underneath the sidebar. This appears to be mostly a WP core issue based on their assumption that Gutenberg always loads fullscreen?

@senjoralfonso I had a similar problem after updating to 3.5.05. I don’t know if it’s template-specific, or something else, but I had to edit the UI Template. The Page Content block in my particular case had a overflow: visible Style property. I changed it to overflow: auto, and I’m able to scroll in the admin UI again.

I’m also seeing a possibly-related problem in some Formidable pages, which are also fullscreen. Parts of the uipress interface are z-index-fighting/overlapping with fullscreen admin pages. Based on this behavior, I’d guess that similar things might be happening with any admin UI that doesn’t load the normal WP sidebar.

Coming back to add that this appears to only be happening when using the default WP admin bar. If I create a uipress Frontend toolbar and assign it, then the issue doesn’t manifest.

@admintwentytwenty thanks!

Just to make sure there’s not something else going on, did you remove the “Dynamic loading” and “Load frontend outside frame” options in the latest release?

Just coming back to add, that this bug is now also causing a conflict with the Bricks builder theme. Their developers have been making ongoing improvements, and one of those is adding the role attribute to the tabs of tabbed containers. So any click on a tab is making that element disappear.

I do not know why this has taken so long to fix. Editing one line of code to add a more specific selector is all that’s necessary.

fastspring-public.js, line 30:

if(event.target.hasAttribute('role')) {

to…

if(event.target.closest('.fastspring') && event.target.hasAttribute('role')) {

Because of the way that this JS file is enqueued, I can’t even figure out how to unhook and then rehook my own version. I have to download the zip from the WP repo, manually edit it, then upload that modified version of the plugin—making it vulnerable to overwriting.

If anyone decides to do this, too, you’ll probably want to find the version variable in class-fastspring.php and edit it from 1.0.0 to something else to bust the browser cache.

Just adding that this looks like the same issue, here, from over 2 years ago. Similar issue with the “role” attribute on any clicked item being hidden.

https://www.ads-software.com/support/topic/header-main-being-set-to-displaynone/

and a similar issue described in this comment:

https://www.ads-software.com/support/topic/seems-like-this-plugin-has-been-abandoned/#post-15292446

Also, since basically every item in the WP frontend admin bar has a role attribute, it makes using the menu impossible anywhere that the fastspring-public.js loads.

I came up with a similar workaround, but it’s not ideal—on a previous version it worked as expected.

@admintwentytwenty, could we get a response?

@frussane have you had a chance to report this to uiPress support?

@jtewes any updates on releasing a patch?

• This reply was modified 8 months, 1 week ago by blakmarkit.

bump?

I see that in 3.4.04 there was a check added in BackEnd.php for Elementor’s editor—presumably you could add a similar check for the Bricks editor (and maybe others that might have issues)?