Roots Discourse

The sundown of Classic Editor and how to develop with ACF + Sage 9/10

So I work in an Agency environment the dev teams day to day tech stack is:

  • Bedrock
  • Sage 9 theme (no bootstrap or tailwind, just empty)
  • Classic Editor
  • ACF Pro

We generally build themes from scratch that our in-house team of designers give to us.

Until recently I didn’t know that the Classic Editor would be going into sundown:

For us this will force our hand to move to using Gutenberg development if there is to be be no support of the classic editor at some point.

After an brief investigation on how we would continue to use Sage and ACF I found this…

It seems a nice and clean way to begin but if we’re to move to Gutenberg I would want to take advantage of the chunking of the CSS and JS etc… which is why I recently posted this tread after playing with the idea…

Adding custom style entries to the browser refresh on yarn start #21333

In our theme development I would also like to strip out all the native Gutenberg blocks and just have our bespoke ones to use as our designs are extermely tailored to specificatoin and design which I know how to do.

Sorry for the long winded explanation, here’s my question…

Do any of you out there have a good way to develop with Sage and Gutenberg in a similar way or one in which we could easily adapt to from our current setup?

Sage 10 is better supported at this point, and it seems much of the community uses ACF Pro with it and Gutenberg. For example: Log1x/acf-composer: Compose ACF Fields, Blocks, Widgets, and Option Pages with ACF Builder on Sage 10 (github.com)

It is very easy to disable core blocks. Keep in mind however the server rendered blocks are less performant than native React blocks, and meanwhile with theme.json it is easy to enable / disable inputs on core.

That’s interesting, I wouldn’t have thought so.

I mean, with a good computer like devs have, it’s probably true. But my instinct tells me that cached server rendered blocks would be more efficient for many users with average computer.
But it’s just a feeling, maybe I’m wrong. Did you read something on the subject ?

To be clear (and I wasn’t haha), I’m talking about within the block editor. Frontend shouldn’t matter whether it was saved within dynamic or client-side blocks (because indeed everything is behind layers of cacheing.)

It’s in the official docs: https://developer.wordpress.org/block-editor/how-to-guides/block-tutorial/creating-dynamic-blocks/

There’s a little discussion here:

And also just from personal experience – ACF blocks are slower than client-side.

Not entirely sure where to go from here then because in the way we develop a theme/template we literally strip out/hide the core wysiwyg editor for all post type templates and just use ACF to build out content.

This might seem strange but our sites are fully bespoke to in-house designs and so with the loss of Classic Editor we’d be left with stripping out all native Gutenberg blocks and building out templates using custom Gutenberg blocks with ACF instead.

All of it is possible but seems rather labour intensive and with you saying it could also be a slower loading experience I’m not sure it’s a viable option?

Your users would deal with a slower editing experience. Serverside render blocks are workable in the editor.

But, I’d recommend studying the block editor and figuring out how to level-up your workflow. We used to do everything via ACF, but with the block editor we’re almost to the point where we don’t use it. (However, many folks use ACF extensively with Sage 10 & block editor, and certainly using ACF blocks in conjunction with core / other blocks is a very viable workflow)

There’s great content from https://richtabor.com/ & https://www.youtube.com/c/HighriseDigital that might match your business segment.