Inner Blocks - How to populate blocks with correct content

[Bryn]

I’ve looked around and not found a solution for this, if one exists.

By default, configuring the first of many blocks within an inner block area for WordPress/Gutenberg produces the correct quantity of blocks in Gutenberg and the frontend, but they all have the content of the first block. Basically what we see in all the Pinegrow tutorials.

This is a big problem for me. If a particular part of the website has a content brief, a developer is expected to follow it. I cannot tell a client to insert a Gutenberg block for the first time and to then start filling in huge amounts of content because my block is not correct. In some cases, like with FAQs and documentation, this can be a crazy amount of info.

What I need is for everything to work as it does already, but instead of mindlessly duplicating the same block for however many matching sibling blocks Pinegrow detects, to have the content carried across too. Such behaviour makes so much more sense anyway. It doesn’t look good when even simple Gutenberg block don’t have their bullet points or feature blocks correctly populated with content.

Is there currently a solution for this in Pinegrow?

Other than this uncertainty, I am so far extremely impressed by what I’m seeing. Seriously top quality product.

[jonroc]

The only solution right now is to hand-type your complete template in the Inner Blocks template setting.

[Bryn]

That’s the conclusion I came to as well, and the main reason I refunded Pinegrow and moved on to another solution. I love Pinegrow but if I cannot provide custom blocks that are correct, this product is unusable to me.

[adamslowe]

Maybe I’m missing something obvious in your question, but wouldn’t crewting separate blocks do what you want? In other words, don’t put anything inside the div that you assign the inner content action to.

Yes, it’s nice and easy to create your outer and inner blocks together, but keeping them separate prevents the Block Editor from automatically adding that inner block as you mention.

[Bryn]

That wouldn’t be viable. Many types of blocks are repeated many times, and I need the repeater functionality to work as one would expect. Creating a ton of separate blocks, especially granular things like FAQ questions, would be an appalling user experience. The admin user expects to insert a block, have it conform to the design/content brief and be able to control repeater elements in an intuitive manner.

It’s a crying shame that Pinegrow didn’t approach this in a better manner. Repeating the first block as many times as sibling blocks exist is a maddeningly useless approach to Inner Blocks.

[adamslowe]

Here is a screenshot of what I’m talking about, which I think is similar to your example.

The ppd-accordion block has a block inner content inside it that only allows ppd-accordion-item blocks.

Then, I create the ppd-accordion-item block and tell it that it can only be used inside the parent

If I created the ppd-accordion-item under the inner content div, then I get the thing you are trying to avoid, where the block is automatically added. But by creating it outside that parent, I have full control.

The result is that the only block type I can add inside the ppd-accordion block is the accordion item block, but inside that accordion item, I can add whatever type of content I want for the “body.”

[Bryn]

I don’t have an issue with using Inner Blocks besides the repeater content. I simply want all instances to be populated with the correct content rather than be a duplicate of the first one. It’s not a question of having more flexibility with what can be inserted.

For example, an FAQ section needs to have all the questions and answers correct upon being inserted in Gutenberg, and not have 20 identical questions because they’re all duplicates of the first one.

[adamslowe]

Ahh, my apologies, I somehow missed that you were trying to use a repeater to populate the content. I just assumed that you were using a regular block with block content.

I have done something with repeaters, but it wasn’t pretty. In the image below, I get the button links from an ACF repeater.

To loop through the repeater items I had to use “PHP Code” WordPress actions with the the_row() ACF function.

I had to use two actions on the div to create the items, then more actions on the anchor to set the links.

The “insert before” code for the div is

// Check rows exists.
if( have_rows('ggg_links') ):
 
    // Loop through rows.
    while( have_rows('ggg_links') ) : the_row();

and the code for the “insert after” part is:

   // End loop.
    endwhile;
 
// No value.
endif;

Then, on the anchor, I used the following code to get the button text and link from the repeater.

The part that infuriates me is that the ACF content doesn’t render properly inside the WP Editor, as you can see in the image below. I’m sure there is something I’m doing wrong, but I haven’t figured it out yet.

---

Similar, but different example:

I’ve also used Pinegrow to create a block to show a set of posts (the three posts on the side in the image below) using ACF Page Links.

This one was much easier. I just used a Show Posts Smart Action with a get_field() function in the “posts to load” setting.

[Bryn]

Sorry for ghosting you @adamslowe ! And major kudos for such a detailed response!

I wasn’t referring to an ACF repeater but the repeated inner blocks. I see now that my FAQ example could have been worded more clearly.

If I understand Pinegrow’s philosophy correctly, are you guys saying that the intended way to handle inner blocks is to only ever provide the first instance of a repeating element like FAQ accordion, image gallery item, service or product card etc. and to then fiddle and faff about with the rest of the content within the Gutenberg editor, totally separate from any workflow within Pinegrow?

I can only assume that is the case, because if I have all the content perfectly laid out within Pinegrow (e.g. 15 FAQ items), the export couldn’t care less. It will just repeat the first item 14 times.

I’ve used ACF repeaters extensively with Oxygen and Bricks, but given the native (and hugely more convenient) approach to block-based development available with Pinegrow I’d rather stick to that. And in any case, an ACF repeater doesn’t resolve the issue as it simply requires a different approach to pasting content within Gutenberg, and won’t work at all on pages or posts without the ACF repeater (unless I use loads of option pages).

I find this situation so confusing. I mean, Pinegrow can already understand what’s going on. It knows that an inner block is used x number of times in the Pinegrow editor and will ensure that the inner block is repeated to cover the same quantity in the block layout within Gutenberg. Instead of just mindlessly duplicating content, why not use the unique content that’s available?

[jonroc]

I think the major issue here is the PG WordPress Extention is a theme/block builder, but you want PG WordPress Extention to work like a website or page builder? Technically you can build a website like you would an HTML website (or page builder like Webflow) and export that to WordPress, but then you limit the user’s ability to update/add to the website from inside WordPress. In WordPress Theme building, all the content/data for a WordPress site is edited in the WordPress admin page/post editor area, which is a good thing in most cases. The theme (which is really what PG is for) is only there for style and general structure.

In other words, data is a WP thing, and structure is a PG thing. IMHO, keeping them separate works out better and is more flexible for the end WordPress users who do not even need to know PG was involved in the website at all.

So when I build an FAQ block I may have 3 inner blocks show by default, but they will all be generic and say things like “Enter Question Here” and “Add a short answer here” as filler text instead of prepopulating answers and questions in Pinegrow where a user can’t access the content.

If I did want some FAQs that are already filled in on a page, let’s say general FAQs that are used on several pages, then I’d create a custom post type called FAQs and enter my Questions as the post title and my answers as the post content. Then I can create a block that is a loop that will output all the FAQs in that post type inside every FAQ block I add to a page in the WP admin editor. This is how I’d “pre-populate” FAQs on a page.

I hope that helps clear things up a bit for anyone looking into populate content in a block vs. allowing a user to populate the content themselves.

[Bryn]

@jonroc

Thanks for the reply. Yeah, I think this is something I’m coming around to. Just a slightly different workflow in some scenarios, but nothing that should be an issue.

[jonroc]

My pleasure,

I thought of two more ways I “pre-populate” a block.

1. You can create a FAQ block in the manner Bryn is speaking of but of course, all the blocks will be the first block repeated in WP. Go into WP and fix all the other FAQs in the editor the way you want them to be (like how they were in PG before exporting), and then make that FAQ block a reusable block. Now anytime you use that reusable block on any other page it will display the same FAQs. It will also update all pages the reusable block is on when one of the FAQs is changed or a new FAQ is added. This avoids the need to create a custom post type for FAQs.
2. If you are using an FSE theme you can create a WP Pattern that has all the FAQs pre-filled in. Then a user could select the pattern and it will output all the FAQs.

[Bryn]

The reusable block approach is a good shout @jonroc! For my upcoming project I’ll probably use an ACF repeater on an options page, but the methods you mention might come in handy in others. A dedicated CPT is also a good approach depending on the quantity needed.