Browser: Chrome 110 OS: macOS / Windows / Linux / etc. URL: Sorry no link publicly because of adult content.
So I needed to create a floating cart button to mimic CartPops cart plugin (correct - essentially there are two cart buttons on every page). In other words there is now a second floating button on the bottom of the website that should open the side cart. The floating button is created with the toggle element. It opens the side cart fine but here are the issues where the mini side cart behaves differently once the toggle is clicked:
a. on press the page scrolls back to the top when the side cart opens up
b. can not close the side cart via click anywhere but need to use the X button
I use the Mini cart #brxe-jdasqe ID as a CSS selector and as a value: show-cart-details.
//EDIT: whats happening with the default button:
whats happening with the toggle button:
On closer observing there is missing the “active” class for the toggle in: <div class="cart-detail off-canvas right cart-detail-jdasqe">
I can’t seem to be able to add it via value. Using “cart-detail-jdasqe” as selector and “active” as value does open the side cart too but the issue stays the same. Any solution for this?
//EDIT-2:
I guess here lies the bug. Using “cart-detail-jdasqe” as selector and “active” as value does not add “active” to the classes.
But for instance using the word “test” as value adds “test” to the classes in <div class="cart-detail off-canvas right cart-detail-jdasqe">
Thanks for your reply. I thought I’m going nuts because of setting it up wrong. One would think a workaround is to put a duplicate of the mini cart element into the floating button, but this increases the DOM size a lot and loads the canvas element twice on every page. In my view a no go.
Using the class “cart-detail” and not the ID as selector solves the issue with the jump to the top of the page at least. But the “active” class is responsible for the other issue.
However, this is not working in current version as Bricks has a “Click anywhere” to close Woo Mini cart by default. When the mini cart is active, a JavaScript event takes over document click events and automatically closes the mini cart if the clicked element is unrelated to it. Consequently, even if the Interaction adds the “active” class, it is promptly removed, as if it were never applied in the first place.
To address this issue, we will introduce a new setting within the Mini Cart element. This setting will allow you to disable this behavior, enabling your Interaction to function as intended.
Hi there, thanks for the detailed update as I wanted to ask how the progress is. I would never came up with the solution to have the selector written like this [data-script-id=“brxe-dzowjv”].
So I must say I’m not quite sure what I should understand from your message, because I set the toggle button like in your example and now the mini-cart does not show up at all. But the Offcanvas menu which I use for the mobile pages opens up. This makes no sense for me on the first sight as it is a completely different ID. So to break it down. It does not work right now and you posted the settings when is going to work in a future release?
//Edit: I guess because I removed the entries in this fields now and the toggle looks for the offcanvas element by its own which is weird. So one is not allowed to leave this field empty as it will trigger the offcanvas even if you don’t want it. The mini-cart does not open for me with your solution above.
//Edit: Ok. So this was wrong:
[data-script-id=“brxe-dzowjv”]
And should be written like this:
[data-script-id=“dzowjv”]
But I end up with the same issues as with my solution. The mini-cart keeps being open and “Click anywhere” is ignored with the custom toggle.
//Edit: Well, fighting one issue brings up another. I do not know if this is 1.9.4 related but the Offcanvas element opened by the Toggle element via #brxe-qwaceg selector worked fine the last weeks. Now if one re-opens it after it was closed one time, the close (X) button is missing. It seems the same issue as Bricks does not know that the menu is open… Really this is getting nuts
Display: none; does not get removed on the second opening of the offcanvas element. This is really frustrating I must say since with Bricks constantly fighting bugs… The display:none attribute is not there on page load. Gets added after the first Toggle and never gets removed…
PLease see my last edit above. I have now the same inconsistent issue with the Offcanvas menu. So you saying not use a Toggle at all? That written in the docs to use the toggle to open up the Offcanvas element
//Edit: I fixed the issue with the Offcanvas close (x) button disappearing after the second open.
To the Mini-cart Button. I created the button like you suggested. Nothing happens on pressing it. The same for the icon. There is nothing happening in the dom on clicking
Yes as I wrote: On fighting one issue another appeared = Offcanvas. That issue is resolved but it seemed very related.
The initial issue opening the Mini-Cart element with the toggle is still the main issue here.
Nothing happend pressing the button / icon element because of quotation marks from the forum:
[data-script-id=“dzowjv”] is not [data-script-id=“dzowjv”]
But still the mini-cart is not opening up. You can see above what I set to those specific elements.
In 1.9.4, if you want to control your mini cart via custom Interaction, please turn this ON.
See my initial message from 23 October!
b. can not close the side cart via click anywhere but need to use the X button
This is essentially why I opened up this thread. I want “close on click outside” to be working with the custom trigger. I want the custom toggle/button/icon whatever to behave exactly like the one that comes with the mini cart element. With the custom trigger the cart only closes on click of (X) button. Which is not good or desiderable.
My apologize as I missed out the point that you want to use a custom button to Open mini cart + you want the click anywhere to close behaviour working at the same time.
If in this case, I would suggest you to use custom JavaScript instead of Bricks Interaction.
On your floating Icon/ Button element, add this attribute
Amazing!! Works like a charm. Thanks a lot! Since we see more and more ultra wide monitor on desktop (I have one myself since several years), it feels wrong to offer the user a icon to its cart on the left bottom but force him to go to the very right top to close his cart. Nearly the max movement. Now it would be great to find out how to tune the slide in animation of the mini cart canvas. Not smooth at all. Looks like it is on a low frame rate.
The Offcanvas slide In is just using simple transform:translate(0) + transition: all 0.3s ease-in-out to achieve.
You can overwrite them if you like.
Thanks!
My apologize as I missed out the point that you want to use a custom button to Open mini cart + you want the click anywhere to close behaviour working at the same time.
If in this case, I would suggest you to use custom JavaScript instead of Bricks Interaction.
On your floating Icon/ Button element, add this attribute
Unfortunately I have to catch up on this issue. I really sincerely have hoped this topic is fixed and I can move on. But…
The floating mini cart button is in the header template. The button is set to fixed positioning. The header it set to be sticky on scroll. Now I noticed once the user scrolls down the header disappears and the floating button also. (But before it disappears it jumps in the container of the header for the transition time of show/hide)
So well I thought no big issue, I just put the floating button into a section template and set the conditions. Well, the button stays where it should be now but the button does not open the cart anymore. So I’m standing there either to fix that the floating button gets hidden or to figure out why it isn’t opening the cart anymore being no part of the header where the “Woocommerce Mini Cart element” sits.
Do you happen to know why its not opening the cart anymore?
It’s hard to help without a link.
Can you send it here?
Or you could email to help@bricksbuilder.io and include this forum thread URL as a reference.
I will check it
I figured out myself but this hole system is really wobbly. I can trigger the mini cart with bricks ID f.e. #brxe-qfllkt. But if I set my own ID for the mini cart element like #custom-cart, the viewport scrolls to the top on opening of cart with the toggle. This is not wanted. The user should stay there where he is. I really don’t get why assigning a custom ID for the Mini Cart element and using that for the toggle is resulting in different behavior. This to be noted, I configured the mini cart element to be a global element so it is the same for the two header and two polylang languages. This is the reason why I wanted a global custom ID. Otherwise I need to have 4 different toggle buttons and therefore 4 templates. With the custom ID would need just 1 that is the same for for both languages.
First of all, I understand your frustration when encountering certain issues and don’t know the root cause. I am not sure the “whole system is really wobbly” is meant for your custom solution or Bricks builder.
Truly believe every problem has many solutions, maybe you picked the imperfect one? Let’s share your link and describe it properly and we will assist as much as we can.
For example, you can use a unique CSS class instead of CSS ID if CSS ID is the issue culprit.
I am not sure why your viewport scrolls to the top, could it be some additional interaction set? custom JS?
If the issue has been resolved and case closed, let’s move on
Its cleary not solved I was just too early happy to hopefully finally ends this. The whole system of Bricks is wobbly in this regard. Just an example. For instance
You can set up attribute to onclick → toggleMiniCart()
Then you would think you can leave the CSS selector in content → toggle blank. But no, if you have mobile offcanvas menu it opens this up and you stand there guessing. So you can put whatever out of your imagine in there to stop if from opening another offcanvas.
Then Woocommerce Mini Cart. Even though it is set as global element, it gets different IDs. Then you go and set them to the same ID but the mini cart icon still refers to the prior ID.
Then you have the interaction where you basically can do the same and break even more. I can go one…
You don’t know how much error chasing I went for a freaking toggle of an side cart before I open the thread. Really unbelievable. Turns out now that the issue why this freaking jump to the top happens and other abnormalities, is because the mini cart in the header and it interferes with the “Sticky Header” & “Sticky on scroll” attribute… On scroll down it does not open the mini cart at all it So on scrolling down the cart does not open and if the user scroll up the cart pops up for no reason. This is your JS not mine.
I made a video of it to prove it and would like to make it public but since this is an adult page I won’t…
Look at CartPops. This is how a good cart is done.
The way of communication sounds really cheeky to devalue my request for help and pointing out usability flaws. I always work as simply as necessary to achieve results as quickly as possible. This has nothing to do with any particular configuration or out-of-case situations. A floating cart button is a very, very common feature, even if this is not Bricks point of view.