Fragments vs standard WP templating


In the process of creating a reusable structure for my future Cwicly websites, I’m testing fragment based architecture to see if it is more efficient than WP standard templates.

So, first, what I want to achieve (most of the time) is this kind of standard HTML markup:

header tag
main tag
- article tag
-- header tag
--- h1 tag
-- post content
-- social share, CTA, comments, etc.
- sidebar div
footer tag

With WP templates, I need to create a default template for each type of page (post, page, archive, 404, etc.) and add my main tag div and recreate the page structure inside each.

It is not that hard, but there is redondant stuff, like the main tag div or adding the page header template part (and potentially more with CTA sections, common archive loops, etc.).

With fragments, I’ve come to this setup: only single.php WP template with main tag div wrapping a unique “content” fragment that deals with everything.

Note that I have to set visibility conditions for each content part in fragments, whereas with default WP template I don’t need that since each template already handles those conditions.

So, my questions:

  • is this the right way to do this in Cwicly?
  • is it future proof regarding Cwicly’s templating strategy? No future changes in all this fragment mechanism?
  • are there flaws in the long term I cannot detect now? (like in one year, I need to add something somehere with some condition and I cannot do it with fragments)

Because with standard WP templates, I know where I’m going (at least I’m going the WP way), and even though I need to repeat a few gestures, I don’t have to mind all the visibility conditions combinations, growing with complex sites.

Besides, reordering template parts in a fragment is not possible, that’s why I wonder if I actually use it properly :wink:
Like, I inserted my page header after the page content, and now I can’t move it before, so I need to recreate the whole structure, which is not acceptable if it is working like this.

Another difference is that WP templating allows to see and edit each template part inside a template editor: for instance you can see and directly alter global header or footer or page header if you’re editing an archive template.
I find this very handy (note that you can hide them if they are in the way with the Cwicly eye icon).

Finally, I think I can reproduce most of the fragment system with template parts and insert them in my default templates layouts with conditions if needed, so I can’t decide which way to go!

What is your experience with this?

Well, after trying in vain to organize things with fragments, I ended up redesigning all with templates and it’s much clearer.
Also you benefit from the visual previews in template page, which is pretty nice.

Then, I watched the video about fragments again, and then I think I understood something: fragments are not meant to be used to build or organize everything in a single template or multiple templates, but could rather be considered as WP hooks that can be used to inject stuff globally with full condition management.

So you can add fragments to your pages/templates at specific locations, and then activate the visibility of the associated template parts according to time, user role, etc…

I guess the idea here is that you can group template parts thematically and manage visibility more easily than editing each template or page where those template parts are used, as well as add new template parts at given locations without opening actual templates.

Main use case for me would be a site with multiple dynamic topbars/headers/banners/ctas/popups.
Could be useful for member sites too, with private sections, displaying profile/download pages or any data according to privilege…

Feel free to correct me or add your own use cases or examples :wink:


Perfectly summed up, couldn’t have put it better myself.

A fragment can hold a multitude of different template parts depending on the query, but occupy a specific position in a template (and multiple templates).

Good point about reordering the template parts :+1:

1 Like

The above discussion shows me, that it would be helpful to have a fully fledged, fully funcitonal and structured best practice site example one can download/ or log into its dashboard and examine it, e.g. with respect to template, template parts and global parts structure and use, where custom templates and template parts are used instead of standard ones, the use of fragments, where what content is put directly into a specific template vs. having it placed in a regular page/ post etc.



Thanks for your description of “Fragments”…I’m struggling to get my head wrapped around the concept and the use cases.

The closest analogy I can come up with based on your description would be what the Oxygen Builder refers to as - “Reusable Parts”.

Oxygen’s Reusable Parts are essentially any collection of elements inside a container that you decide to simply “package up” for reuse elsewhere on your site. What was nice about the way that Oxygen implemented this was you could make the decision to create a Reusable Part at any point in your workflow, i.e. while designing a page/post or while designing a theme.

Then, when building a page, you could add any of your Reusable Parts to a page like any other element. Also, when adding an Oxygen Reusable Part to a page, you must decide whether it should be editable or non-editable on the page.

Anyway, I’m not 100% convinced this is analogous to a Cwicly “Fragment” but I’m beginning to suspect that the there are some similarities.

Would be much appreciated if anyone else in this community who has a grasp of these two constructs could share their perspectives. :face_with_monocle:

Hi @webworx,

For the block editor:

Non-editable “Reusable Parts” sound quite analogous to WordPress Reusable Blocks.

Editable “Reusable Parts” sound analogous to WordPress Block Patterns.

You may find this summary interesting:

@Louis also described some exciting planned Cwicly features about having Cwicly “Components”, which sound like they will have both editable and non-editable parts and as such will be even more powerful.

Thanks @StrangeTech for the clarifications.

However, my core question relates to the Cwicly Themer rather than the WP Block Editor.

I just cannot get my head wrapped around “Parts” versus “Fragments”. Despite my best efforts, I cannot find a clear coherent explanation of what these are actually. For example, the Cwicly YouTube video about the Themer states the following:

“…it (the Themer) also allows you to add global parts in order to add notices in fragments, which are template parts added to a fragment that can be applied in any post which you can set specific conditions for…”

This is an exact quote from the transcript of the video. If you parse this, you get - “…fragments are template parts added to a fragment…”

I’m not making this up. :upside_down_face:

So now what do I do?..I have no idea what the Cwicly team are talking about when it comes to Parts and Fragments so it is not welcome news that they are planning to create “Components” to further the confusion on top of the Block Editor’s existing set of confusing objects and terminology.

With respect to the current version of the Cwicly Themer, are you aware of any resource that clearly and coherently explains what a “Part” is?..and, what a “Fragment” is?..and, perhaps the use case for both in the context of Templates?

Would very much appreciate any guidance on this topic.

Hello @webworx,

I’m sorry for the confusion here around template parts and fragments.

That’s about it :slight_smile:

More specifically, and from the docs:
Fragments are collections of template parts that can be used globally across multiple templates.

Fragments were introduced to allow you to group template parts within a specific area of a template or post, while allowing you to apply visibility conditions to each of those template parts individually.

Please let me know if that clears things up.

Hi Louis,

Thank you for this, I truly appreciate the effort.

They say a picture is worth a thousand words. And, in that spirit I think that it would be tremendously helpful for new Cwicly users to have some simple diagrams, drawings or graphics of some sort to illustrate how Cwicly Templates, Fragments, Template Parts, Global Parts and soon “Components” all fit together.

I’m not complaining…or, at least I’m not intending to, but I’m finding that I’m investing too much time just trying to understand the Cwicly Themer constructs especially given that your excellent YouTube videos apparently use an older version that references “Global Parts” whereas this particular construct is nowhere to be found in the current Cwicly Themer UI.

Anyway, in summary - pictures please whenever possible. :pray:t5:

Cheers! :slightly_smiling_face:

Hi @webworx,

Just jumping in here to let you know that “Global Parts” have become Fragments:

New Cwicly users do have access to this information, as it is explained in the Getting Started > Beginner Guide > Cwicly Themer page:

Though the UI has changed (which we have noted and will make sure to update the images as soon as possible), it remains the same.

Please don’t hesitate to let us know if you have any further questions!

So Fragments is kind of like Kadence hooked elements?

To an extent, although one obvious distinction between them is, the Kadence hooked elements are based on the hooks for areas present in classic themes as opposed to the block based themes.

With block based themes that use templates, we as developers have a lot more direct control over what is included in any given template, including dynamic content, so in-template hooks are not as important.

Therefore the Fragments are really best suited for global elements (e.g. headers, footers, banners, etc).

This part is so powerful.
I use fragments for things like testimonial/quotes, CTAs, or things that end up being used in lots of different pages or post templates. Speeds up workflow and you keep a single source of truth. It would be nice to have a visual preview, but I can mostly live without it.

You can get more granular and have it read in dynamic data. I use fragments for blog post cards, listing cards, inner content for repeaters, etc. If the visual should look the same, but the data will change dynamically, it’s a very efficient way to make use of it.

This is why Cwicly and WordPress are such a powerful combination. There are many ways to achieve the same result.

We do something very similar using Reusable Blocks instead of Fragments. It is great for following a DRY approach.

I’ve given up fragments for now and use reusable as well, because I have simple needs.

But for more complex site with lots of dynamic CTA, ads, A/B testing, etc, I guess I would use fragments to have easier and more granular control on conditions.

Agreed, for global CTA blocks and banners we use Fragments.

It’s easy to switch them on and off using visibility conditions either on a per page basis or based on other logic such as for switching to maintenance mode.