From old feedback: Remove Lock In | Cwicly
Cwicly blocks are currently unavailable when the plugin is not installed, resulting in a content lock in. Would be great to be able to convert Cwicly blocks to Gutenberg blocks or at least give the user the possibility to recover content.
And also possibly the ability to convert from core Gutenberg blocks to Cwicly blocks, for those who are moving to Cwicly from core layouts or from another builder that has the ability to convert to Gutenberg blocks.
Agreed! This has been one of the main concerns I’ve had so far when it comes to building for clients.
This is a difficult one. Thanks for bringing it up again.
With our last big update 1.1, we moved towards the Gutenberg official rendering system.
It ended up being a nightmare because of the poor handling by Gutenberg in block updates…
So we reverted to dynamic rendering which means that content lock-in is still an issue.
We are currently figuring out the best ways to save users from basically losing their content etc…
One proposition was to provide an extra plugin that would allow users to convert Cwicly blocks (whether Cwicly is installed or not) to Gutenberg default blocks.
Hey @Louis,
I’m curious as to what your long-term regarding lock-in is?
I often hesitate using any kind of block plugin within my blog post content. I know that if I do, I’m pretty much deciding to have that plugin active forever unless I want to update hundreds of elements across various blog posts.
I know many people say “well why would you ever want to deactivate it?”, but plugins get acquired, die, cause issues etc.
I think it’s smart to look at what-if scenarios 5 years into the future.
With Kadence Blocks, once you deactivate the plugin, most blocks convert into HTML and essentially leave you with whatever text that was there.
This is a step ahead of Cwicly, but I know that’ll come in the near future.
What I’m moreso curious about - do you think there’s a future where you could disable Cwicly and have all the content AND styling remain?
I’m guessing that it would need to be done with some kind of static element converter.
I can’t think of any other plugin that is capable of this, but it’d definitely be cool if you could disable the plugin for whatever reason and have static HTML & CSS remain.
*PS I mostly ask this because of the “Export your blocks, posts and templates with a one-click solution to ready-made HTML and CSS elements.” item on your roadmap 
Hey @sunny,
I completely understand the worries you have with being locked in.
Cwicly definitely needs to provide a quick way to convert ALL blocks to HTML blocks just like the Regeneration functions we currently provide.
The trickier part is with the block CSS, but I’m currently going with the idea of simply including it as a <style> tag if the block is converted. While not totally “legal”, it means that you won’t need specific logic to import the page specific rules.
Global classes and stylesheets are fine as they are.
Most of our blocks already have the HTML ready-made as I pointed it out in some other thread, so we’re not that far from making this possible.
Yes! I think the above solution would do this perfectly.
The only difficulty I see currently is that you have to be able to convert both ways… So we would have to be careful about that, although we can still keep all necessary attributes as html comments.
My guilty pleasure feature Hopefully we can come to a solution that’s comparable to Webflow’s
The fact that you’re even thinking about any of this is awesome.
It can seem counterintuitive to build functionality around ‘when the user uninstalls our plugin’, but it truly does help some people (like myself) feel more free to use the tool in the first place.
Plus it’s just better for the web 
I sometimes build custom blocks with ACF Blocks, but using a visual editor like Cwicly would just be quicker and a lot more enjoyable.
Hah this is exactly what I was thinking as well. If it does somehow prove to be too illegal, even just having one external stylesheet with all your block styles would be 100x better than nothing.
Without block defaults, it’s possible that the consolidated stylesheet wouldn’t even be that massive.
Inline styles would still of course be best though if actually possible.
Gutenberg official rendering system offers out of box compatibility with any SEO plugin or translation plugin like WPML as most of them ship with a HTML parser. It also solves the lock in issue. But the block recovery is a mess as you said. This is how Stackable handle depreciations of their blocks. Just posting here in case it helps. Stackable/attempt-recovery.js at aeba7373a305ef32a35c5006e98777e0b7737227 · gambitph/Stackable · GitHub
Hi there @dranzer,
Thanks for the share.
This is indeed interesting as a way to bypass the Gutenberg verification.
Definitely food for thought in the way they get around this serious problem.
Indeed, 1.2.7 should help reduce lock-in.
A big thank you @dranzer for sharing Stackable’s way of doing things, which hinted to the way they deal with on-page deprecation.
Is there an update to this? It would’ve been wonderful if it could work like Bricks.