Time to retire linked blocks feature?

Just bringing this thought up as a general discussion point.

Whenever I’m poking around in the Cwicly UI, I notice the option to toggle Link Copied Block(s) or insert a linked block from my Collection.

Every time I see it, I catch myself asking “how does that work again?” “I don’t want to insert a linked block, right?”

I understand how it works, but for whatever reason it still feels like an obscure concept. Not to mention, it has significant limitations compared to just using global classes (difficult to trace back, easy to accidentally delete the source etc).

I was thinking - now that Cwicly has global classes + the ability to copy/paste styles, is there any benefit to having this feature? Or does it create confusion in the UI (especially for new users)?

Curious to hear if anyone’s currently actively using it.


I’m quite a bit confused now and seeing others backing your post doesn’t make it better either :pensive:

I’ve also seen you mentioned global classes when talking about the copy linked feature, but I couldn’t find anything about virtual classes, which play a significant role in this case.

So my question is, how can I achieve the behavior like using the linking feature without using the linking feature?
I might miss something here, but I still think this is a really powerful feature and I can’t see why it should be removed.
What even changed in that regard, except that a more streamlined and decluttered experience was provided?

Could you please elaborate on how this is directly linked to the linked blocks feature?

Again, I might even misunderstand the entire concept of that feature.
But your entire post doesn’t make sense to me.
Maybe someone can point me in the right direction.

1 Like

Thanks @sunny for bringing this up.

Same sentiment as @Marius here, not sure why linking blocks would not have a use in Cwicly anymore.

The role of the linking feature is to allow you to copy the styles of an element (by applying the block class as a virtual class) without having to recreate those styles in another block (and duplicating css at the same time), while keeping those styles specific to the post/template they were created on.

I do find myself using block linking a lot when I don’t want to have to create global classes that don’t have any reason to be global.

Just to give a bit of context for those that might not see the point of linking:

Imagine you have your column setup with all the nested blocks inside.
We want to add another column.

  • Duplicate the block → duplicate of every class style, which makes your stylesheet size increase drastically. Want to change the padding of one element inside the column? You’ll have to do that for every element that you’ve repeated inside every other column.

  • Simply apply the virtual classes manually

    • Duplicate the blocks = having to remove all the styles manually block by block.
    • Add the blocks one by one to the column = consumes a lot of time
    • Add the specific virtual class one by one to the elements you want to control
  • Copy link the block → all the job is done for you. The column and nested blocks have their relative virtual class added automatically, and styles + content is removed.

There are a lot of times I can see the linking feature extremely useful, and this really is just a way to enhance something that you can do manually.

Can we improve it? Sure.

A quick hover over the virtual class could highlight the reference block?

A notice/warning if the block class is used as a virtual class within the page before deleting the block?

As usual, we’re open to changing/improving on things. But currently, I don’t see us removing this feature.


I discovered the linked block watching a Cwicly tuto. It is a formidable feature.
It is sometimes difficult to find who is the child, the parent or where it is…
The proposal to:

  • hightlight the children when hover the parent
  • hightlight the parent when hover a child

with different colors (in the display area and in the navigator) could be a great feature.
Some kind of “dot” (with the colors defined above) on the item in the navigator could be added.
The info will immediately appears: this item is a child or this item is a parent or both.
Another proposal following the above one is to set a system of arrow (just like in Excel when the are ciruclar reference error) in the display area or in the navigator.

Thanks @Marius & @Louis for the thoughtful responses. This might actually be a more interesting topic than I initially thought.

Edit: Novel incoming.

No need to worry! The whole purpose of the post was just to open a discussion and get feedback like yours.

Of course, the suggestion to remove a feature isn’t something that would affect me personally.

It’s more thinking about Cwicly’s user experience in general and providing whatever feedback we can to make sure that when a new user tries the builder for the first time, they feel like “this is for me.”

Any time a user feels friction, it compounds, and I was initially thinking that the Linked Blocks feature might be something that creates friction.

This is interesting. I hadn’t really framed it as using a class but without needing to add it to your global stylesheet. I can see the appeal in that.

But here’s where I struggle with it.

In what case would using Linked Blocks be considered best practice?

If you’re building a standard site, you’ll want to be able to reuse sections and components across different pages.

Even if you think you’re just using it for this one page, you may change your mind down the road or want to run an A/B test.

If that ever becomes the case, you’ve left yourself in an undesirable position because if the master block ever gets removed, you’ve lost your styling everywhere.

Edit: it looks like if you delete the master block your linked styling still remains on any other page you pasted the block on. However, you can’t actually edit that styling anywhere now.

The second issue is developer hand-off. Client-First by Finsweet is a framework for Webflow, but this part of their methodology has always stuck with me:

  • To create a Webflow build that is scalable and easily manageable
  • To help developers, clients, or anyone understand the project

A Webflow developer, client, or any person should be able to understand what a class is doing based on a class name, even if that person has no experience with Client-First.

Linked Blocks are an abstraction from these principles.

Imagine someone else at your agency has developed the site, and you load up a page that’s utilizing linked blocks. You click on a secondary instance block and you:

  • Have no idea what styling is being applied
  • Have no idea where the styling is actually coming from
  • See an autogenerated class name that doesn’t describe its utility

The first two could be tweaked with UI changes. The last one could potentially be resolved as well if you rename the autogenerated class, although when I tried that it looks like the linked styling still just gets applied to the auto class.

The last thing is feature complexity. It seems like a simple feature on the surface, but the more I play around with it the more I realize how much logic must be going on in the backend.

Let’s say someone has the base understanding. When you create a linked block, it simply adds the autogenerated class of the first block as a virtual class to the second block. And those block classes only exist on the page that you’re on.

But then you go to another page, add something from your collection, and see the option to add a linked version? My brain goes “error error :robot:.”

So classes can be copied from one page to another.

And when you copy a block from one page to another it still works. But if you add styling to a nested element on the source page, it doesn’t get reflected on your new page even though the class names are the same.

As you can see, it just feels like there’s a lot of logic that the user needs to understand. And that creates friction.

Don’t get me wrong, I can see the benefit of the feature. If you’re building a one-off landing page or are trying to build as quickly as possible, it treats your stylesheets better.

But is the benefit worth the complexity?

And does it help web designers build a better, more scalable website?

Ladies and gentlemen of the jury, those are the facts I present to you in this case.

In all seriousness, these are just some personal thoughts & observations to consider. Even if only helpful for tweaking the UI in the future or adding to the knowledgebase.

If users are finding the feature useful, then please leave it as is!


Just wanted to chime back in here and say that with the new design library, I now see the benefit of linked blocks.

They’re like global classes but local to your page.

Global classes are still best practice when building out a site, but linked classes are helpful when creating one-off designs or importing sections from the cloud.

The only thing is that I do still think they are a contributing factor to Cwicly’s learning curve - probably because no other builder has them, so the concept is new.

How to make it intuitive for the user so that they don’t need to read documentation or run their experiments… that I’m not sure of yet.

But just wanted to say I see their utility now :slight_smile:

From my perspective I can say, this feature is very prominent and frequently used inside the YouTube tutorials.
It’s actually impossible to not notice it.

Very good explained, different use cases, even with dynamic content examples, etc.
The added value of this feature was always emphasized and easy to follow.

My impression from your post before was that problems has been constructed which I hardly could follow.
It would be interesting to know what other users think to get a better understanding of the overall situation, especially since you received some positive reactions from others.

Don’t get me wrong @sunny, if you think there is room for improvement, I appreciate any comment/opinion. We are all here to make things better.
This feature actually evolved quite a bit already in a very positive way.

I sometimes tend to see things as solid or even perfect, until someone appears with a solution or improvement which I never thought I actually needed.
Do you have specific suggestions for a better experience?

Apparently, this feature seems to be a clear case for the Role Editor :man_shrugging:


I love the concept of this linking feature but I have to be honest and say that the user interface is not making sense for me right now as I struggle to simply link/duplicate a paragraph block and it’s styles.

I have created my paragraph block, turned on the ‘link copied blocks’ indicator and duplicated my block. But when I go to the original block and change the font size the copied block font size does not also change.

Not sure what I am missing but I am being perfectly transparent in my lack of understanding here so that the Cwicly team can learn from my user experience.

It’s actually copy linked, not duplicate linked.
Try copy/paste, instead of duplicate.

Duplicating a block fulfills another purpose.

1 Like

Ok, well that makes sense in hindsight :sunglasses:

However, I am still having issues …

I select the paragraph block
turn on the Link copied blocks feature
copy the block with CTRL C (also did so via menu drop-down)
but when I try pasting the block with CTRL V nothing happens and there is no Paste command in the dropdown menu

again, I imagine I am missing something

I recorded a screencast of my process - the Cole’s notes version is that key commands don’t allow the paste function and the block menu also doesn’t allow the paste function. The only way I was able to paste a copy of the linked block was with the right-click contextual menu (which doesn’t display in my screencast but the results do).

the pasted block did work for style changes on the main block but the copy paste process is not user friendly at all as far as I can see. @Louis am I missing something here?


Watch Video

I see.
The missing paste option inside the Navigator context menu was already pointed out here and there. Hopefully, it gets added at some point.

There are some issues with the copy/paste functionality.
For me, the update didn’t fix it. There might be improvements but can’t comment on that.

We have 2 options to select a block. The Navigator and directly on the canvas.
If copy/paste is not working, I select the block from the other option, this works in most cases, sometimes it requires some hopping between canvas and Navigator.
Hope that helps in the meantime.

1 Like

Ok, thanks @Marius , it is helpful to know that I am not the only one experiencing it.

1 Like

Hello @smontreuil,

I’m sorry to hear you’re having trouble with pasting blocks.

This is an unfortunate situation as the team and I cannot reproduce this issue on any setup (Windows/Mac) we have going, when using the keyboard shortcuts.

Are you using the latest WordPress version here?
Also, could you try going to Clipboard Inspector and paste your copied block there? Knowing the type and data that is being retrieved might help us debug this more efficiently.

I might also add that the linked copied block toggle doesn’t have to be toggled when copying the block, but when pasting it.

1 Like

Hi all,

I’ve been playing recently with linked blocks, and I have to agree with @sunny first messages about maintenability (copy-pasting across pages, deleting master, etc.), team working, hand-off, etc. This can become very confusing and not intuitive.

I insist again on the local aspect of the “linked-type” virtual classes, like @sunny mentionned, and if the whole class system was a bit clearer about that, I think this would avoid some confusion.

See Class system thoughts and How to attach virtual (previously additional) classes to blocks? - #21 by Marius.

I also faced @smontreuil issues a lot, and it made me lose a lot of time reseting all styling after having duplicated some huge structure instead of copy-paste, or trying to paste in vain.

I actually really can’t figure out why duplicating doesn’t behave like copy-pasting… What am I missing?

In the end, I see the power in linked blocks and virtual classes, and I love using them now (@Marius told me I would get used to them :wink:), but I think for most users their potential is hidden behind a counterintuitive UI and vocabulary. I can imagine, well, in a very limited extent, that FSE and WP/Gutenberg constraints give you some hard time implementing Cwicly, but just a bit more attention on this would be a game changer and would really make Cwicly shine even more way above the competition.


Hey there @Louis, I didn’t notice this reply from you until now and it is so far past when I originally posted my concern that I am unable to comment in any kind of helpful fashion. Thank you for being available to address all of our concerns!

1 Like