Difference between Global Parts and Template Parts

I wonder what is the difference between creating a Template Part (for example a Header) and applying display conditions inside a Cwicly editor (Image 1) and creating a fragment inside Global Parts and applying display conditions to the fragment itself (Image 2)

Image 1

Image 2

Hi @Dev.tomi,

The main difference here is that in the case of the template part, you have to insert it manually inside every template you create.
With the Global Part, it is automatically added to the top of the <body> tag of every page (depending on conditions of course).

While I do prefer adding the template manually (it allows me to have a complete view of the design in the backend while editing), quite a few of our users prefer applying Headers and Footers outside the template creation area, allowing them to add/remove Header and Footer items more quickly if needed.

It comes down to a preference of workflow.

I would also add that adding conditions inside a template part means that that template part will appear in the markup, even though it doesn’t contain anything.
We’re currently looking into removing the template part wrapper so that only the elements you add inside appear in the markup.


This is actually something I am really looking forward to.
Didn’t expect, that would be possible - so fingers crossed.
Great news :tada:


Thanks for explanation!

I was about to say, this would be pretty cool.

I actually never considered that the template part was yet another wrapper. It doesn’t really “feel” that way intuitively, but I never thought to check the markup.

@owynter Tbh, I avoided using template parts because of this extra wrapper. I know this is far from being smart and not taking advantage of great existing functionality.
I’m always looking for best practices and trying to solve a lot with CSS instead or just using extra Divs.

These divception pagebuilders really made me kind of sick and forced me to leave WP.
Coming back from custom builds where I have 100% control of everything is a bit hard for me here and there, but I somehow had a good feeling from the beginning when I came on board. 5 months later now, still no regrets and more confident than ever that Cwicly will be the next big thing.

So removing the extra container is kind of big for me.

I am with you 100%.

I don’t use the Cwicly Section block for this reason :sweat_smile:
Just roll my own with a couple of divs. So much cleaner, and easier to keep control.

But this is exactly why I love Cwicly. It is the closest thing to handcoding out right now. FWIW, I love Oxygen for this very same reason. I just hated how slow it was (4.0 supposedly fixed), and how inaccessible it is to people who are non-devs, which is why I looked into Cwicly in the first place.

Yeah, I also plan to do the same same.
Just waiting until it will be possible to have optional ID’s and classes available to find my perfect setup.


I’m kinda surprised of 4.0, expected a lot less. Never was a big fan and probably never be, but I understand why people using it, I have some o2 background as well.
While I think Cwicly has a bright future, o2 will face some major issues in the future (but that’s another topic).

Would love to hear your thoughts on this… in an appropriate forum, of course. Looking ahead at projects in my pipeline, and most are going to be on Cwicly. If we get a codeblock… block soon, then there will be even fewer reasons to stay. That, plus a dynamic slider would cover almost all of my needs.

@owynter You can build dynamic slider even now, with the help of 3rd party libraries like Swiper JS or Flickity. It is pretty easy, I plan a tutorial on this but I am tight on schedule :confused:

I’ve used SwiperJS before. Simple enough.

I have been spoiled by OxyExtras’ implementation of Flickity on Oxygen Builder, though. Very easy to get it done.

It’s something Cwicly will need to add, though, as many won’t want the challenge of implementing a 3rd party library.