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