Here’s another question, if you are going to build guberbug blocks then why on earth would you need an ACF field that emulates the guberbug editor? It’s going to eventually let you edit “side bars” or whatever they end up calling them, so there will be no real need to have different sections of blocks. The plan is to make the entire front end page editable with the new editor, meaning that there is no real reason to have separated “sections” to edit.
Why would you need another instance of the block editor?
And another question, why would you put a WYSIWYG editor into an ACF block built to work in guberbug? Wouldn’t you just create text fields, text area fields, and other types of fields and then format those fields in the block to appear the way they need to appear?
Are you asking, will ACF let you nest the block editor inside of itself? Why would you do this? Wouldn’t you just create multiple “blocks”?
After thinking about this for a while the entire question confuses the hell out of me as to what use it could serve.
Granted, I’m on the other end, I dislike guberbug and I feel it is a bad decision. That is based on knowing the types of clients I serve and what their needs are. The last thing my clients want is for any editor to be able to putz around with the site design. I plan to built in 100% ACF fields.
But I’m still paying attention to what’s going on and where this disaster is headed.
Please explain what purpose this could serve?
Welcome to the Advanced Custom Fields community forum.
Browse through ideas, snippets of code, questions and answers between fellow ACF users
Helping others is a great way to earn karma, gain badges and help ACF development!