Prepare Flynt to be compatible with Wordpress 5.0

[bdbch]

Pretty soon (19th of November) Gutenberg will come out in combination with Wordpress 5.0. ACF created a cool solution for ACF support which is pretty straight forward.

https://www.advancedcustomfields.com/blog/the-state-of-acf-in-a-gutenberg-world/
https://www.advancedcustomfields.com/blog/acf-5-8-introducing-acf-blocks-for-gutenberg/

The implementation looks awesome and makes editing easier for content editors since there is a good way to show a preview of the current data set.

Looking forward to get this feature working in Flynt!

[domtra]

Hi @bdbch,

first of all, let me please apologize for the long delay of my answer. This topic is very complex. A lot of the decisions made regarding Gutenberg integration will shape the future of Flynt.

I am really impressed with what ACF has done to integrate Gutenberg. I think so far it provides one of the best developer experience when it comes to creating block. It also makes WordPress server know about blocks which is something really important in my point of view.

I also think that the Gutenberg experience is an improvement to the current tiny mce post_content field and that it will offer a nice alternative for the flexible content bits of some Flynt projects.

Gutenberg, however, although it will be integrated into WordPress by default starting in version 5.0, is not as ready as I would like it to be for professional projects. There are still many open questions on how Gutenberg can and will be used.

One of those questions is the use of server side rendered blocks and the awareness of the WordPress server about these block. In the Gutenberg docs, the ServerSideRender component is described as a way of integrating legacy blocks into WordPress and that it should not be used when developing new blocks. The suggested approach for new block is JavaScript only, rendering the blocks in the browser and saving its markup to post_content. This will lead to the same issues we were facing with other page builders in the past, where we had to change all posts that include a specific component if we want to update/edit its markup or some global variables. In Gutenberg you are able to write block migrations and will get a notice that markup has changed if the content in the db differs from the one that is rendered in the browser, but, to my knowledge, there is no way of bulk updating all occurrences of a component in the db if some part of the definition has changed.

Another challenge is the theming of blocks. Gutenberg is not a perfect representation of the website's frontend, it is not an in place editor. This means that you need additional or slightly modified styles just for Gutenberg in order for a block to be displayed nicely. If there is custom JavaScript functionality in a block you also might not want this to be executed in the backend. For example, a slider might work exactly the same in the front and backend, but if you trigger some additional actions (eg for tracking) in the frontend, you have to make sure that these do not get loaded or executed in the backend as well.

When it comes to page templates, what blocks are allowed, are there fixed ones, is there something like flexible content and if so on what position of the editor, there are solutions, but I do not know if those will cover all the use cases we today use with ACF only.

Coming back to acf_register_block(), while it does offer the best developer experience I have seen so far for Gutenberg blocks, the integration into Gutenberg is not that seamless. I understand the distinction between the edit and preview modes, but a custom coded block would let you edit everything possible in the preview area itself and only have hidden options editable via the sidebar. In this sense, I understand why Gutenberg encourages you to write client side blocks only. It will be interesting to see, what a good compromise can be between these two approaches. A way to define where an ACF field should be rendered (content or sidebar) might be something to try.

Also I noticed that all the values of the fields of a block will be saved in post_content in the block definition. This will help reducing the enormous amount of postmeta that ACF saves, but you might need a bit more flexibility to allow having these values saved in the postmeta or custom tables all together.

All of this tells me that integrating Gutenberg into Flynt at this point will raise many more questions than it will solve and that despite Gutenberg being the default editor in WordPress Version 5.0 it is not as mature as I would like it to be.

However, this does not mean that we do not regularly evaluate all options and will have some updates on this soon.

I definitely encourage you to install the beta version of ACF 5.8 and use it with Flynt. A basic integration is done with a couple of lines of code, depending on what exactly you want. And you need to disable the CleanHead feature and remove the hooks for disabling post_content.

Let me know if you need any other assistance or want to discuss this further.

[bdbch]

Hey @domtra thanks for this good and informating explanation! I guess you guys spend a lot of time already evaluating Gutenberg for a longer time. I totally understand that hopping on Gutenberg without knowing the future about Gutenbergs support on server-side blocks is quite dangerous and not suggested right now. Didn't know that server-side blocks were not an intention of the Gutenberg developers and using Javascript only blocks feels wrong considering how inconsistent code on Wordpress pages becomes after a few code changes on the javascript block. Still don't understand why they don't bother server-side blocks before client-side blocks since they make it so much easier to maintain.

I'll look into a quick test with Flynt and Gutenberg but rendering a good example demo in the Gutenberg editor compared to the actual output of the page in combination with all layout styles is still an open book for me.

No worries about the long delay too, I totally understand the daily-business struggle! :)

Good answer which I totally appreciate.