Refactor workshop template to increase flexibility

[iandunn]

Background

#186 will require some changes to the block template, to add new elements to the page. Currently, the template is hardcoded in post_content via the template assigned to the CPT.

https://github.com/WordPress/learn/blob/beacb50998a874fc5f90dd134074c8a59f9b313c/wp-content/plugins/wporg-learn/inc/post-type.php#L142

The template has some "primary" user-generated content like paragraphs/lists describing Learning Outcomes and Comprehension Questions...

https://github.com/WordPress/learn/blob/beacb50998a874fc5f90dd134074c8a59f9b313c/wp-content/plugins/wporg-learn/inc/post-type.php#L169-L207

...and "secondary" content like programatically-generated workshop details, a join button, and a code of conduct link.

https://github.com/WordPress/learn/blob/beacb50998a874fc5f90dd134074c8a59f9b313c/wp-content/plugins/wporg-learn/inc/post-type.php#L208-L236

Problems

Because of the way it's setup, changes won't apply to existing posts automatically, like they would with a traditional theme's single-workshop.php template. We'd have to manually update old posts to use the new template. There have already been some changes to the template, so many posts are using different templates. See WordPress/gutenberg#7961

It also hardcodes the "secondary" content into post_content, when it should be applied dynamically. That content isn't supposed to change between posts (other than i18n, which can be handled dynamically). Right now there are non-English posts that have the button in English, because it wasn't translated in post_content.

The block template also allows the sidebar content to be removed, because template_lock isn't inherited to Column blocks. See WordPress/gutenberg#8112 and WordPress/gutenberg#9386.

Potential Solutions

We started discussing the issue in https://wordpress.slack.com/archives/C01KC5VDQBC/p1614641586017200 and
https://wordpress.slack.com/archives/C01KC5VDQBC/p1614645458026200.

It looks like WordPress/gutenberg#26128 helps solve some of the locking issue, by letting us control modifications to a column.

There doesn't seem to be a straightforward solution for storing the "secondary" content outside of post_content, though. I looked into how FSE might help that, but it doesn't seem like the beta is far enough along to be useful in production. I'm guessing we'd likely run into problems implementing exactly what we want, and would have to change stuff once the MVP is done. I'd be happy to be corrected about that, though, if anyone sees a way I missed.

If not, I can see two ideas:

1. Just update the current block template w/ the new fields, similar to how past changes were done. Then, either: A) ignore old posts; or B) manually update old posts.

2. Create a "workshop" block, and make that be the only thing in the template. This may not the "correct" way in a post-FSE world, but it might be a decent compromise today.

   1. The block's render function could use InnerBlocks to define the template. But the block would have distinct Edit and Save components.
   2. Edit would display the "secondary" blocks -- so that the user has a WYSIWYG experience -- but Save would only save the "primary" content into post_content. The secondary content would get saved to post meta. For the WPTV embed, Save could pick the URL from the Embed block and save it to a post meta field, so that we wouldn't have to modify the Embed block itself.
   3. Then, the traditional theme template (wp-content/themes/wporg-learn/single-workshop.php) would render the "secondary" content dynamically.

Does anyone have any thoughts?

@ryelle , @noisysocks , @StevenDufresne , @coreymckrill

[iandunn]

I played around w/ option 2, and I've made some progress, but it feels like it's probably gonna take more time than it's worth. So at this point I'd say #186 should just do option 1 for now, and then we can possibly revisit this when FSE is stable.