Anyone using Vibracart Pro in Elements? Are you happy with this solution?
Pros/Cons?
While Vibracart Pro looks like a great solution, and it’s really encouraging to see developers building components for Elements… dev components are not built to be distributed to users. They are for development purposes only.
Here’s a quick overview on distribution from the developer docs about Dev Packs.
Element Dev Packs are for internal use only. Do not distribute or sell them.
An Element Dev Pack (.devpack) is designed strictly for local development. These are uncompiled and unencrypted versions of your components that allow for live editing and testing during development.
Every file inside a Dev Pack is actively monitored by Elements and the system, which enables real-time updates as you work in third-party editors, a huge benefit while building components.
However, this live monitoring comes at a cost. If too many Dev Packs accumulate over time, Elements (and macOS) can run out of file handles, leading to components failing to load or update. To avoid performance issues and ensure system stability, Dev Packs must never be shared or sold.
That said, Dev Packs are fine for internal use. If you’re collaborating with a small team, doing client work, or running a closed beta, it’s okay to share Dev Packs privately for testing and feedback. Just be mindful that these packs aren’t encrypted or optimised, and should never be used as a final delivery format.
Before distribution, all Dev Packs must be compiled and encrypted into standard .elementpack files. This process protects your code, improves load times (down from seconds to milliseconds), and ensures the pack is safe and optimised for use by others.
You can learn more about Dev Components here.
We’re working hard to provide developers access to the Elements distribution platform, and we’ll have more news on this later in the year.
Hi @dan,
I am trying very hard not to be contentious but I fail to see what the difference is between using a DevPack that one developed privately (which is the case with my Blog, Calendar and Carousel DevPacks which are all being used on my production site) and with the @vibralogix Sitelok / Vibracart Pro DevPacks which Adrian has made available via his website. I use the Sitelok DevPack on my site.
I could have developed the Sitelok Devpack myself and then used it on my site as it would be mine?
As DevPacks aren’t encrypted, I can easily see the code that the @vibralogix DevPack generates for the Sitelok components.
Adrian is just providing the DevPacks so that Elements Users can use his products. The use of Sitelok is essential for my site, as it was when it was a RW Classic / Foundry 3 / Alloy site.
I appreciate one significant difference is that these DevPacks are being supplied outside of the Elements Store but that will change once you eventually deliver the capability for 3rd parties to use the store for their products. In the meanwhile, this strikes me as a very useful, helpful and reasonable stop-gap. 
1 Like
I’ve explain above why distributing Dev Packs to customer is not a good idea, and that’s just the tip of the iceberg. You can learn even more about why Dev Components shouldn’t be distributed in the Docs.
Have a read of that, and then come back to me with any specific questions.
Hi Dan,
This is same conversaton we had before. My clients have updated to Elements from Rapidweaver and need to use VCpro and Sitelok. I have now paid for an Elements license for the last 2 years and still have no way to distribute my free components. On the link you sent over it still just says
Information on converting your Dev Pack into a distributable Element Pack will be available soon.
When will this be? You seem to spend lots of time developing your own components for sale but refuse to open the store to anyone else (people like me and my clients who have supported Realmac for years). Instead of complaining when anyone else tries to distribute their own components in the only way possible maybe open up the store to third party developers.
1 Like
Hi Adrian,
Totally hear you, and sorry this has dragged on longer than either of us would like.
The short version is that Dev Packs are not a supported end-user distribution format, and the compile/encrypt to .elementpack workflow is scheduled for 2026.
We’ve been building the distribution platform in stages because it’s not just a storefront. It includes packaging, encryption and signing, updates, licensing, payments and refunds where applicable, and protections against broken or unsafe packs. That foundation has to be solid before we open it up more widely.
One important bit of context: we actively asked Elements users where they wanted us to focus. The overwhelming feedback was to pause work on the store and finish missing or rough areas in the app itself. That’s what we’ve been doing, and it’s why store access for third-party creators has taken longer than any of us would have liked.
On the point about us working on our own paid components, that work is also how we stress-test the same pipeline third-party developers will use, and it helps fund ongoing development. The goal is not a closed ecosystem. Third-party creators will be a core part of Elements in the future.
For your own projects, internal teams, or limited client work during a build phase, Dev Packs can be a practical stop-gap. They’re just not something we can recommend for public distribution or as a final customer deliverable, and we can’t reliably support the issues that come with that model such as performance overhead, lack of encryption, and no update mechanism.
We genuinely appreciate you sticking with us. We know this is a key piece for long-time RapidWeaver developers, and we want to deliver a first-class path that’s safe, sustainable, and worth the wait.
1 Like
Hi Dan,
I do understand that but what are existing clients supposed to do? You have persuaded users to switch from Rapidweaver to Elements but they then find out they are unable to use any external components. That means many sites are not transferable.
As @logrunner said there is no real difference between sending a component to a user and them creating the same component (typing it in) by themselves. Either way there maybe some efficiency issues that the user will have to suffer (I explain that to them) but that is only temporary while we wait for the store. The number of users we are talking about is very small anyway.
On a more general note about components. If locally created components cause so many issues with file handles etc are you saying that even cusotm components will end up requiring to be put in a dev pack even for internal use only?
Hopefully in a few months time, this problem will be a thing of the past.
2 Likes