Convert Shortcodes to blocks

[bph]

by @jonathanbossenger

Case study of how to approach shortcut conversion, using Seriously Simple Podcast plugin for some "real world" examples, that now has both, regular blocks and the dynamic rendering option, based on the requirements of the block.

[jonathanbossenger]

Brain dump

1. Intro to React
2. Intro to Webpack and how it works with your current setup
3. Not every shortcode should be a block!
4. Intro to create-block
5. Converting simple shortcodes that use default block edit/save functionality
6. Converting shortcodes that make more sense to use the dynamic block rendering
7. Creating custom components to reduce redundancy
8. Using apiFetch to get WP data to power blocks
9. Using core-data to get WP data to power blocks
10. Where to find information (navigating the block editor handbook)

[jonathanbossenger]

@bph I have asked folks to comment on this ticket with comments/ideas/suggestions of things to cover, in the hopes that it will help uncover the hurdles folks are experiencing. I'll probably leave this open for about 2 weeks, and then get cracking once I've gathered whatever feedback I get.

[alanef]

Looking at it the other way around, every block should have a shortcode!

Why? Because of the dozen or so popular page builders that all understand shortcodes, but don't understand blocks. ( Or maybe, encourage all page builders to understand blocks / incorporate Gutenberg?)

Assuming the former, as a plugin dev having two code lines one for blocks and one for shortcodes is a hard thing, but having three code lines, one for shortcodes, one for block editor and one for block display is even worse.

This is just random thoughts, not structured.

My path has probably been a typical PHP/jQuery path of many devs in this space, so a jump into REACT for just the editor is a steep learning curve which I'm maybe 6 months into and only scratching the surface.

Shortcodes are dead easy, just a couple of lines of PHP with a text editor and you are up and running.

Blocks are harder unless you have a local dev env, node / npm installed then create_block is useful, but a as plugin dev it was no use until the recent --no-plugin option was released.

But there still is the unanswered question in my head 'What is the appropriate architecture for a block/shortcode plugin without duplicating functionality across the code lines'.

[justintadlock]

I have asked folks to comment on this ticket with comments/ideas/suggestions of things to cover, in the hopes that it will help uncover the hurdles folks are experiencing. I'll probably leave this open for about 2 weeks, and then get cracking once I've gathered whatever feedback I get.

I have converted several shortcodes to blocks, and the one thing I still struggle with is getting data, such as posts and users. For some reason, I never wrote a simple shortcode. :)

Here are some examples that I painstakingly cobbled together:

• Post types: https://github.com/x3p0-dev/x3p0-archives/blob/master/resources/js/block/edit.js#L33
• Posts: https://github.com/x3p0-dev/x3p0-archives/blob/master/resources/js/block/edit.js#L83
• Users: https://github.com/x3p0-dev/x3p0-list-users/blob/master/resources/js/edit.js#L42

When I was building those bits of code, I never felt like there were any good resources for getting the data I needed on the JS side (something that has always felt super easy in PHP).

"Getting data and doing something with it" is probably one of the most important things for plugin developers, so any extra focus in that area helps.

[andrewlimaza]

I have asked folks to comment on this ticket with comments/ideas/suggestions of things to cover, in the hopes that it will help uncover the hurdles folks are experiencing. I'll probably leave this open for about 2 weeks, and then get cracking once I've gathered whatever feedback I get.

The main hurdle is the tooling around here and not fully understanding webpack. We tweak the wordpress/scripts webpack to adjust the entry and output points to fit our file structure. What we need is to output to assets/js and entry point would be /blocks (with various subfolders).

Right now, it nukes everything in the assets/js whenever you use wp-scripts start or build. Not sure if this is a NPM version thing or if there's a setting we can use to keep pre-existing files (other .js files for plugin frontend/admin etc) and just rebuild the files we need (i.e. blocks.build.js).

Also a standardized file structure for blocks (within a plugin) would help us, this is something we're working on for our own team (not paving the way for WP) but with the ever evolving tools and understanding of blocks we need to neaten this up internally as we built blocks before wp-scripts was a thing or we just didn't know about it (I can't remember 5 years ago what was our thought approach). We have moved over to wp-scripts ever since which made things easier but still gets confusing to troubleshoot this when things don't work. Our goal now is to to move to a set file structure and webpack config in upcoming plugins that already have shortcodes and other /js files. We have made some workarounds but I don't feel that these are ideal.

Here is an example where we adopted blocks early on and you may see the file structure we'd typically work with - https://github.com/strangerstudios/paid-memberships-pro (Most of our shortcodes and pages have turned into blocks to make working with our plugin easier).

+1 for justin's comment, getting data wasn't easy and often confusing (when coming from PHP to REACT).

[jonathanbossenger]

I have converted several shortcodes to blocks, and the one thing I still struggle with is getting data, such as posts and users.

TIL about the core-data package! I just ended up using apiFetch package and DIYing it. Might be useful to cover both options

[bph]

@jonathanbossenger
I finally looked over the outline, and 1 & 2 can be taken care of by linking to existing pieces, like workshops and documentation. There might even be something in the Block Developer course introduction. Not every blog post can start at the beginning. I would start in the meat of the matter, and guide readers to the existing documentation for deeper dives.

Start with 3. Not every Shortcode should be a block!
Even create-Block has received lots of attention in other tutorials (Docs, learn). A link might suffice here as well.

Good luck!

Thanks for commenting also @andrewlimaza - That's in interesting observation. Come to think it if, I am also confused about how Webpack and WordPress packages interact, and it would be a great separate blog post for the new site. What do you think?

[jonathanbossenger]

@bph this sounds like a good plan.

I'd also be happy to write the "how Webpack and WordPress packages interact" blog post as a sort of "follow-up" once this post is published.