So working on this course at Full Stack Digital, and after creating my block, using WordPress’ create-block package, I saw that the src folder has a named folder which then contains the src files. I looked into this and realised that the create-block package supports multi-block support and I thought that was so very cool. I can create multiple blocks inside the same plugin.

For the block I wanted to create, I pulled out my notebook, and wrote down what I wanted to do, even though I was following along the tutorial.

I started my notes, with wanting block attributes for the block in the editor so that I can select whether it was a major version or a minor update. The tutorial is working with just a string, but I needed to find out the types of content options I have for block attributes, so I went to WordPress.org documentation for attributes, here.

This didn’t quite help though, and I needed some higher level tinkering to figure things out.

I took a wide step back, and looked at what I wanted to do versus what the tutorial was saying.

Starting with the fact that the tut is working with a string and I want to work with a selector, but that I also want to store that selector so that it can be referenced in titles for posts after it, I took a look at this:
<div { ...useBlockProps() }>
and noted that it is shorthand for:
const blockProps = useBlockProps();
<div { ...useBlockProps() }>
but importantly, their function is different.

const blockProps = useBlockProps(); will store the result in a variable, so I can reuse it later, while <div { ...useBlockProps() }> is if I only want to return the value once and not store it. I found this out by reading here about the expected functions in the ‘edit’ and ‘save’ files.

Now, knowing that this would require the use of an Editor component, I went to the Storybook that I learnt about some months ago, and found the one I wanted – RadioControl component.

It took me a while playing around with things, and rereading the documents, to figure out how to wire the attributes to my output though, but I eventually got things working, after a final push in Cursor where I get help with syntax rules, etcetera.

How do I do that? I created a Cursor rule to use all the WordPress.org handbooks as a guide, that I then add to any working folder using this line:
ln -s ~/WPDev/wordpress-coding-kit ./
The wordpress-coding-kit folder contains all the WordPress handbooks as md files. It’s very helpful.

Well, once I got it working, I realised this was just half the battle and will change my strategy. One win, and one glimpse into what’s next.

I do get the updated version numbers depending on whether I click on ‘major’ or on ‘minor’. Now, this is good, but it’s just text in the editor, it’s not my title, and it’s my post titles I would like to be affected by this.

So, next I’ll work on two things:

• editing the core/post-title in some way, directly
• ensuring that the version numbers are stored, so that a new post will update based on the version number from the last post published. As it is now, I set the js so that it would start from 2.8, but that’s not actually what I’d like to do. I need it to start at 2.9 (or whatever version I’m on when I figure it out), but actually be dynamic so that it then takes the previous version number using this method and increases it, based on whether the post is a minor or a major update.

This was a great Sunday!