Thanks. It’s a rare situation for sure but trying to build different page sections and allow the client to add content in the same way throughout. Most of the site’s content was added before Gutenberg was core – just hoping there was some way to keep consistency without rebuilding. C’est la vie. Thanks for the confirmation.
The goal of gubergug is to allow the client to edit the entire page, eventually. Managing these sections all through the block editor. Trust me, I understand this, my clients need structure and none of them should be allowed to tweak the design of a page. Moving forward I am completely removing dependency on the default WP editor and will be using nothing but ACF fields for all content, including the main content. Either ACF will continue to support tinyMCE for it’s WYSIWYG or someone, maybe me, will build a custom field type for it if it’s removed, although I doubt it will be removed. I am not the only person in the world going in this direction.
Actually it is possible with the help of 2 tiny plugins, and a little bit of imagination !
1. The block(s) that are going to be used in TinyMCE must be Reusable ones. So step one is to create the Reusable blocks…
2. Install the plugin “Block Widget” (https://wordpress.org/plugins/block-widget/), this will put a Reusable block in a widget (and only a reusable block) – this is the reason step one was needed.
3. Install the plugin “Widget Shortcode”, get the shortcode for the Nlock Widget from step 2, and place it in your editor.
Still don’t believe me? Watch this … https://www.youtube.com/watch?v=OI4Fe6XZmag&feature=youtu.be
I like where your head is at. I’m in a similar boat – not wanting to be dependent on the default wordpress editor.
Using repeaters and flexible content I’ve created builders that allow me or my clients to build really nice looking pages and blog posts.
In other places where I have pages/ sites that I’ve pre-built, and I want my clients to enter info like a personal photo, bio, email etc I use site options tables, and insert the info wherever necessary.
My issue is that although I can get really nice looking results on the front end, I struggle to get my back end ACF fields to look as clean as other builders.
Thinking forward a few more years, I think it’s really critical, for my clients at least, that the whole editing experience is more or less wysiwyg.
When people see endless commercials for wix style editors, I don’t want my site editing experience to seem a decade behind…
I’m trying to decide if I go all in my ACF page builder and try to make the backend editing look more like the front end results, or if I should try to build custom modules for a builder like Beaver Builder. Either using their global blocks, or possibly continuing to store everything in ACF, but exposing the data into custom beaver builder modules for “front end” editing experience… not even 100% sure that’s even possible.
Maybe a third option is something like what mailchimp does, where you click on a preview and it loads up acf fields to edit in a sidebar. Instead of clicking “add row” in a repeater/ flexible content having a panel where users can click to select a layout. Sounds cool, but would be beyond my current abilities to develop.
I’m curious of your perspective, and if you’ve come across any potential solutions since it doesn’t appear guttenberg will be the answer.
See, my clients want nothing to do with editors where it looks like the front end or where they can edit on the front end. Not everyone is enamored with this type of site editing.
I deal almost entirely with larger companies. Their #1 priority is that every page of the site is consistent. They do not care what the content looks like in the admin. They simply want to be able to add chunks of text and maybe some images and know that it will look like it’s supposed to look and I can’t have any styles imposed by guberbug effing up a well thought out design based on the client’s style guide & requirements because some editor decided to do something different or is not familiar with their company’s standards or forgot something. Seriously, I try to remove anything that requires them to do any thinking about the content layout with very few exceptions. WP is simply the mechanism I use as the data warehouse. I don’t build themes for “general use”, every theme I build has a specific use for a specific client.
I also build fairly complex features into a site that would likely treble the time it would take me to build if I tried giving them something so that they could see what it will really look like and I don’t event want to think about the extra time that building all those custom blocks would add. I deal with bigger companies, but that doesn’t mean they want to pay extra so that the admin looks pretty, they just want it to work and aren’t interested in spending extra just to make the admin show them what it will look like.
And on top of that I need to add fairly complex queries to show the information and without a lot of extra effort it would be impossible to search the content in those blocks to add the needed search filters. Building blocks that also save meta data for searching or using a page builder that requires me to do extra work to extract and save meta data for searching seems like a huge waste of time.
Gutenberg may have it’s place for small sites and bloggers and people that don’t have large demands on their time. And I’m not saying that it will not be useful in some cases. Generally if we have a client looking for something like this we find them an off the self theme that will meet their needs. However, if a client wants something of this nature then they really don’t need me in the first place.
To add support for inner blocks, use the
<InnerBlocks />Component within your render template/callback to define an editable area. This special element will be displayed as a native “block inserter area” when editing content, and the saved “inner blocks content” when viewing content.
// Register a restricted block. acf_register_block_type(array( 'name' => 'restricted', 'title' => 'Restricted', 'description' => 'A restricted content block.', 'category' => 'formatting', 'mode' => 'preview', 'supports' => array( 'jsx' => true ) ));
You must be logged in to reply to this topic.
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!
© 2023 Advanced Custom Fields.