FSE approach to content?

Just saw this video WordPress Block Themes: Don't make this BEGINNERS mistake! - YouTube

And it seems counter intuitive to me. It has not been how I was using FSE. So far I have just been editing directly in the templates. I have no content design separation. It just seems to me like thats just how FSE works.

Have I been doing things wrong? I cant imagine I am supppse to use such a roundabout way as this video suggests.

It really depends on the type of website you are creating and who is editing it.

If you are in control of the entire website and doing the editing yourself, then use whatever works best for you.

If you have clients or other people that are editing, especially people with less technical experience, then it can be very beneficial to separate the layout and global design elements from the page/post content.

So, feasibly, you can put all of your designs directly into your pages and have empty templates with just the post content block OR put all of your page content into the templates and just have empty pages assigned to different templates OR a more separated approach with only the content in the pages and only the design and layout in the templates.

There is no right or wrong way, although separation of concerns is always a good plan for larger, more complex websites, especially as it helps with ease of maintenance.

Luckily Cwicly supports all of these use cases.

3 Likes

I like @StrangeTech’s measured approach.

I’m a bit more dogmatic :slight_smile:

I advocate for separating design from content wherever possible. Quick and dirty does work, and you can spin up sites really quickly. If you’re not too fussed about longevity, then go this route.

Since I am doing mostly client work, I am more disciplined in keeping content and design separate. It requires more thought and planning, but the benefits are very apparent in a short span of time. It’s often easier for less technical people to add/update content, and you can make design changes that reflect across a broad range of pages/posts/elements without as much hands-on work.

The biggest for me, is just future planning. If you expect a site might live beyond 3 years or so, then you should be considering what that future looks like. You may want to change technologies altogether. So many of us using Cwicly now are coming from Oxygen, Elementor, Divi, etc. And have had to rebuild sites from scratch. Since Cwicly has custom fields baked in, I suggest making use of this, to give yourself a lot of freedom in the future.

You may want to move to a headless JS-type setup with a different CMS altogether (Contentful, Sanity, Prismic, etc). Having this data saved separately in the db gives you some flexibility to map it to your new environment.

Even if you’re sticking with WP, it would be easy to get up and running again by just rebuilding the frontend templates and mapping the fields back.

Just my $0.02.

3 Likes

As an example of my approach, here’s a screenshot of the custom fields of a page I’m working on, which contains a nested repeater:

Here’s the backend:

Here’s a snippet of the frontend:

Can you imagine if I had each of these sections as their own editable blocks? It would be a nightmare to keep updated.

As it is, I only created a single section and, with some CSS, I am able to alternate the sections all the way down (there are more, I just cut it off). That’s the first repeater. The second repeater contains the accordion content within each section.

The resource demands of rendering all of those blocks on a single page would be tremendous on the backend. Your work would come to a crawl.

Hi @owynter,

I definitely am also a big advocate for separation of concerns and for keeping sites well organised and structured.

Agreed, quick and dirty is useful for rapid prototyping, aside from that it’s usually never a good idea for a production site and leads to slow and painful later on. Best practices are best for a reason and they will end up saving you valuable time and energy and allow you to be more efficient.

100% agreed. Every client is different and has different editing needs, so, the best thing we can do is be flexible.

Some clients want a more WYSIWYG editing experience and some need a more granular field by field approach.

For less technical clients, having individually editable fields removes any fear they could have of “messing up” the design/layout and helps direct them to exactly the part of the website/page they want to change.

And on the other hand, we have a couple of clients who actually prefer and specifically requested that each section be individually editable directly on the page as it gives them the control they want.

Any way that simplifies the maintenance and updating of the site is usually a good thing.

The more options you have at your fingertips, the more you can adapt and deliver what works best for the client

Thanks for sharing
I am also a fan of the separation of content and design, as it ensures that everything remains consistent with the brand and less technical clients won’t break things.
However, the idea of future-proofing and the potential for a headless approach, as highlighted by @owynter, has given me a fresh perspective that justifies this method.

Before cwicly I use either:

  • ACF flexible content, which unfortunately is not supported in Cwicly repeater yet (CMIIW) so I can’t use it. Brick can do that so I’m a bit envious.
  • Custom ACF blocks. make all sections as Gutenberg blocks. the cons are I can’t utilize Cwicly visual editor for the layout and have to spend more time building all the blocks.

Both systems above allow clients to just stack the reusable sections and focus on content only.

I watched a recent Cwicly live stream, and Louis mentioned components. Which I think will be huge for content editing workflow.

I’d be interested if anyone has another alternative way to manage content.

Components will be an ideal solution, indeed!

In the meantime, you may be interested in this thread:

1 Like

I’m also a fan of using templates and separating out the content … and since this thread started with a video, here is a new one that shows what is coming in 6.3. In it there is the suggestion that in the future pages will be created in the Site Editor! So, it seems things could change.