Try using blocks for block content

[adamwoodnz]

Replace wporg_support_get_forums_list() in functions.php which returns block content, with a server rendered block.

This follows the approach we took with Developer Resources.

There are several more functions which do the same, if we decide this approach is beneficial we can convert them too.

Includes dependencies and scripts for building blocks.

Pros: feels less hacky to have this code which converts bbPress templates into blocks, contained in blocks, rather than output from functions.php

Cons: requires a build process

Is this worth doing?

[ryelle]

I suppose the question is whether we would eventually iterate to a point where bbpress/loop-forums-homepage.php is a block template (html) instead of a PHP template? Because since it's not a block template, we're not restricted by the same technical issues that require a block wrapper in true block themes.

Do any other benefits of blockifying exist here?

• Could layout and other block styles reduce CSS?
• Would blocks help in organizing CSS?
• Any interactive sections with custom JS that could be modernized with the interactivity API?
• Are any simple sections that could be done with core blocks + block bindings? (for example, the Edit button in patterns is a core button block, with bindings that pass through the button URL and text, avoids creating a custom button block)
• Are there existing issues with the new theme that this will fix? or planned enhancements that this will help?

I don't think requiring a build process is a true drawback here, in fact if we move the CSS to src/style, we could drop the grunt step like the other theme redesigns.

[adamwoodnz]

I suppose the question is whether we would eventually iterate to a point where bbpress/loop-forums-homepage.php is a block template (html) instead of a PHP template? Because since it's not a block template, we're not restricted by the same technical issues that require a block wrapper in true block themes.

At this point I don't have a good grasp on how much work this would require, but my understanding is that we're not going to be iterating on this much in the near future.

Do any other benefits of blockifying exist here?

I don't think so, these functions are just returning non-interactive content and require no extra CSS. They already use block markup for styles.

Seems like the previously mentioned pros and cons are actually both pros. For the small amount of effort required maybe it's worth doing just for these and to set us up for the future.

[adamwoodnz]

I don't think requiring a build process is a true drawback here, in fact if we move the CSS to src/style, we could drop the grunt step like the other theme redesigns.

I've now migrated from grunt to wp-scripts, based on the config from the Main theme. All seems to be working fine, although haven't tested RTL yet. Not sure what kind of state that is in before or after these changes.

[StevenDufresne]

I don't see the reward in making this change unless it comes with tangible benefits for our users.

I don't think it makes the developer experience much better, if at all, nor does it future-proof the code based on my understanding of what's being proposed.

[adamwoodnz]

My motivation was mostly coming from a best practice/devex angle, so if no-one else finds the current solution too unpleasant we can leave as is.

[adamwoodnz]

One nice devex improvement with the wp-scripts build is that the CSS sourcemaps work, unlike the current one. I haven't spent the time to fix that, didn't seem worth it.

[adamwoodnz]

One nice devex improvement with the wp-scripts build is that the CSS sourcemaps work, unlike the current one. I haven't spent the time to fix that, didn't seem worth it.

in fact just this build change is worth doing IMO. Replacing the old grunt build removes tech debt and brings devex consistency.