• Resolved blakmarkit

    (@blakmarkit)


    Something about the way that uipress is modifying the frontend WP logged-in/admin toolbar (or body?) is breaking sticky/sticky-scroll behavior on elements throughout the site while logged in. Prior to the 3.5.x refactoring, this wasn’t an issue. I disabled uipress and the elements behaved correctly. Re-enabling uipress causes the incorrect behavior to return. If uipress is enabled, but I’m not logged in, the sticky positioned elements also behave correctly. I haven’t been able to track down the exact cause.

    WP 6.7.2, Bricks (theme) 1.12.1

    Let me know if there’s any other info I can provide.

Viewing 5 replies - 1 through 5 (of 5 total)
  • Thread Starter blakmarkit

    (@blakmarkit)

    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.

    Thread Starter blakmarkit

    (@blakmarkit)

    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.

    So to clarify, when using the default wp toolbar, all sticky elements on your site break?

    Thread Starter blakmarkit

    (@blakmarkit)

    @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.

    Thread Starter blakmarkit

    (@blakmarkit)

    @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.

Viewing 5 replies - 1 through 5 (of 5 total)
  • You must be logged in to reply to this topic.