Hi - Im getting stacks rendering issues in Edit mode when using the otherwise excellent Vibracart Pro stacks. Basically border or entire stacks disappear unless you click on them and it makes life quite tricky when moving stacks around.
I recall seeing this issue in the past - once I believe with Foundry users where switching off ‘toolbox acceleration’ was the solution.
However, this happens with any framework / theme so it does seem to be the Vibracart stacks. Any suggestions?
Yeah, it does sounds like the GPU acceleration in Stacks is the issue, but I could be wrong. Can you post a screenshot of the issue?
Perhaps @joeworkman or @isaiah could chime in on this one?
Hi @manofdogz,
That indeed looks like the problem that Foundry used to fix by disabling hardware acceleration using the switch in the Toolbox stack. That issue started after macOS Ventura was introduced, as it no longer supported the way edit mode graphics were accelerated at the time.
I’m not sure if other stacks (or the Stacks platform as a whole) supports the same type of hardware acceleration, or why it suddenly decided to make your life harder just now. Perhaps you introduced a stack into your project that implements it?
The Stacks platform at the moment doesn’t have a built-in way to disable hardware acceleration unfortunately.
So, in short:
Alternatively, if you own it, turn the project into a Foundry 3 project, and implement Toolbox. Then switch off hardware acceleration from within Toolbox.
Cheers,
Erwin
Stacks relies on the old WebView framework, which Apple deprecated in 2014
and replaced with the more modern WKWebView. As a result, graphics in Edit mode—especially when hardware acceleration (GPU) is enabled—can glitch out, causing stacks to vanish or display incorrectly.
I don’t have time to dig up every old post that covers this issue, but here’s a thread from 2024 where the “Shelf” stack in Foundation 6 was causing problems. The fix in that case was to disable the “Turbo scrolling” option:
Since WebView is deprecated, the only real long-term solution would be for Stacks to migrate to WKWebView—but from what I’ve gathered, that isn’t likely to happen. There was a discussion about WebKit on the Stacks Discord just yeterday, but you need a login to view it so I’ve included the relevant part below.
If these kinds of rendering glitches are starting to become a pain, it might be worth exploring alternatives. You probably know where I’m going with this 
The Elements editor uses the modern WKWebView (and it’s SUPER FAST) under the hood, so editing is snappy and visually accurate. Might be something to look into if you’re running into these issues regularly!
Thanks for the input. Adrian at Vibralogix is taking a look and I’ve given him the feedback re GPU acceleration / WKWebview etc.
No problem.
It seems linking to their Discord about the WebKit issue wasn’t well received, even though we don’t post there, we’ve now been timed out.
It’s a bit disappointing that neither @Isaiah nor @joeworkman are active here to support users of their own products.
I’m happy to help my customers but you will have to post on my community since my account here is censored. Case in point… I cannot post a link that will help you.
Haha. I cannot even post the screenshot that shows my account is cannot post. I bet you will never even see this post.
Hey @joeworkman, welcome back!
Just to clarify, you can post here, as you’ve done.
The reason you’re currently unable to include links or images is simply because your account has a trust level of 0, that’s a standard Discourse restriction for new or inactive accounts (and yours has been inactive for quite awhile). It’s nothing personal, and those limits lift automatically as you participate more.
It’s a shame, because this forum really benefits when developers are part of the conversation. Most users here are looking for help here, not elsewhere, and redirecting them off-site when they’re already stuck isn’t ideal.
Would be great if we could all focus on supporting people where they’re asking for help. That’s ultimately what’s best for the RapidWeaver Community.
Hey @manofdogz, I’d be happy to help you out. However, I’m pretty limited in what I can do here due to account restrictions and lack of access to the tools I use to support customers effectively.
If you don’t mind, please post in the Weaver’s Space community (I cannot link to my website; all links to my domains are blocked), the Stacks4All forum, or the Stacks Discord. I’m active in all three and can give you more direct help there. You can also shoot in an email to my support.
You’ll get faster, more focused support there without the side chatter or bias that sometimes comes up in this space.
Thanks for the follow-up @joeworkman,
We understand you prefer using your own communities, but this is the official forum for RapidWeaver Classic, and users here are looking for help here. Sending them elsewhere, especially without even trying to solve the problem first, isn’t a great experience for them.
Even with some posting restrictions, you were able to reply, and could’ve easily asked a follow-up question or offered a quick suggestion. That would’ve gone a long way.
If your goal is to help users, then helping them where they already are is the most direct and respectful way to do that.
Unfortunately, I have to disagree. If a user is having issues with one of my products, I should be able to support them in the environment where I can provide the most effective help, without arbitrary limitations on links, screenshots, or context.
While I understand the desire to keep conversations on this forum, the priority should always be helping the user get the best support possible, even if that happens elsewhere. It’s not about controlling a narrative, it’s about solving problems quickly and accurately. That should be the goal for all of us.
Totally agree, so why not just help the user here?
They’ve asked a clear question. Instead of making them jump to other platforms, just answer it. That is the fastest and most accurate way to help them.
I hear you, Dan. But helping someone effectively means having access to the tools and environment where I can actually provide meaningful support. This forum restricts how we can communicate, no links, no screenshots, post limiting and approval, and limited context, so most of us devs are simply pointing users to where I can help them thoroughly and quickly.
Let’s be honest: part of the hesitation to engage here is the atmosphere itself. You’ve fostered a lot of distrust over time by policing conversations and framing off-site support as somehow disloyal. That doesn’t create a welcoming space for collaboration, it discourages it.
It’s not about making users jump through hoops. It’s about giving them the best experience, even if that means continuing the conversation elsewhere, without the baggage.
Im not a Foundry user so not an option sadly.
If you can share your project we can take a look and see if we can find out what stack is causing the issue for you?
Post a link here or email it over to forumsupport@realmacsoftware.com
Thanks - it’s definitely the Vibracart Pro stacks and the dev for those is taking a look. In this instance it’s not a showstopper as the Stacks are a nice to have rather than necessary. I’ll feedback when I hear further.
Just observing this discussion from the outside, is the problem not that Joe cannot post the links and images that he needs to provide support here? Would it not help solve the problem to allow him to post images, screenshots and links to the support code here?
Classic users are dependent upon the 3rd party developer platforms, so we need their assistance. Can you not just enable each other to provide the support we need on all the forums, without the ‘turf war’ discussions please?
I don’t wish to start a big debate here, but if Joe cannot reply here because his ability to post helpful screenshots is restricted, isn’t an answer to remove the restrictions so he can post that content for the users who need it here?
Seems that’s the easy way to solve the problem preventing a full support answer to me, as a mere customer who’s observing.
There are plenty of rapidweaver customers who rely on 3rd party developers still, so it’s much better for everyone’s customers if you all try to get along and help the end user wherever they post.
Adrian’s support from Vibralogix is always exemplary and first class, so hopefully he fixes the problem for you @manofdogz. I’ll be interested to follow the results if you can feedback, as I have (but have not yet implemented) the Vibraloxic Cart product.
@JP_NZ Thanks for the thoughtful reply, it’s appreciated.
Joe can post here. He’s not banned or blocked.
The only restriction is that, like all accounts with a low trust level, he can’t currently post links or images, that’s a standard forum setting to prevent spam, and it lifts automatically with normal participation.
In Joe’s case, his trust level remains at zero due to past behaviour, including legal threats made against us and this community.
Since the launch of RapidWeaver Classic, Joe has been actively encouraging users to copy our custom PHP framework files into older versions of RapidWeaver to bypass the need for an upgrade. He’s even published detailed instructions on how to do this (example 1, example 2, example 3).
We’ve also recently learned that Joe has been distributing our custom PHP framework directly, code that’s exclusive to Classic. This undermines the product, encourages piracy, and directly impacts users who support the platform by upgrading legitimately. Note: The original post illegally sharing our framework has been edited: Before and After Screenshot.
Hopefully you can understand why that warrants a more cautious approach.
If Joe genuinely wanted to help, he could’ve replied with a few lines of text, just like others (ourselves included) have been doing.
In this case, the user asked a clear question. Joe chose not to answer it, and instead tried to redirect them off-site. That’s not about platform limitations, it’s a deliberate choice. And unfortunately, it’s a pattern we’ve seen before, where questions are met with sales pitches or moved into closed ecosystems. That doesn’t help RapidWeaver Classic users, it just fragments the support community and pulls people away.
We’re all for collaboration, but that means engaging in good faith and supporting users where they’re already asking for help, not using external platforms to chip away at the community and redirect people elsewhere.
We’ll always welcome developers who want to help. But let’s be honest: this isn’t about trust levels or missing screenshot features. It’s about intent.
Just to clarify one point that was raised:
I shared a method to allow users who owned both RW8 and RW9 to use the newer PHP runtime with RW8, as a temporary fix to enable PHP 8 support where needed. This was intended to help users during a transition, not to bypass or undermine any product.
I did also post a copy of the PHP binary once on my community, intended to assist a specific user (that owned both versions). Once I realized that might not be appropriate, I removed it.
Now that I understand Realmac objects to users enabling PHP8 in RW8 using files from their RW9 installations, I’ve gone ahead and hidden those posts out of respect.
I’m committed to supporting users in good faith, both technically and ethically, and will continue doing so on the platforms where I can be most effective.
