Good day, everybody. Now that we are recording, we can officially kick things off. I was saying
to my co-host Tracy just before everybody joined that yesterday I managed to, I had another call
in Zoom and I had the call, the call went well, ended the screen share and then forgot to press
stop recording and then manage to record about seven hours of myself working throughout the day.
So I will do my best to remember to stop the recording today. But welcome, everybody,
wherever you are in the world as you're joining us. As you join, please let everybody in the chat
know where you're joining us from, what part of the world you're joining from. I always like to
know where folks are from in the world. It's just interesting to me. And then feel free to share a
a little bit about yourself, where you're from, what you do with WordPress,
whether you work with it or use it or extend it.
Give us an idea of where you are and what you do in the chat.
While I do micro-kit introductions, my name is Jonathan.
I am from Cape Town in South Africa, which is right at the bottom of South Africa,
which means travel anywhere is a schlep.
I am a developer educator at Automattic,
and I am sponsored to work with the training team.
And if you want to find me online, the best place to find me is at my website, JonathanBrasinter.com.
It's been my WordPress blog for about...
Gotta work it out now. 15 years now. Wow. That feels like a long time, but I'm sure there are
many of you that will be blogging with WordPress for a lot longer than that. Okay, so we've got
Gerald, welcome from Ovada, Colorado. Aaron from Sacramento, California. Plug-in developer,
welcome, Aaron. We've got Rico from Switzerland. He's an IT teacher. Welcome, Rico. Hey, Adrian.
I'm from Anaheim, California. Hi, there. I have a few small business sites that are run on WordPress.
Mark from the UK, WordPress developer of products and websites. Matilda from Costa Rica, freelance
web designer and use WordPress to make sites for my clients. Awesome. We've got Tina from
South Florida. We've got Jim Coatesville. We've got Laura from North Carolina USA,
website designer owner, contributor to the training team. Come join the team. Yes,
absolutely. Do what Laura says. Hi, Laura. We've got Matt from, I'm guessing, PA
is Pennsylvania, I guess. Thank you Adrian for the thumbs up there.
Matt says he's a front-end developer from Digital Agency.
I only very recently discovered how close New York,
City, Washington DC and Philadelphia are to each other. I had no idea. To me, they were just
names of places, but I'd recently discovered how close they are to each other. So that was
That was quite interesting.
I'm slowly getting a good handle of, you know,
West Coast, East Coast, North, South,
not that, learning all these places.
That's one of the reasons I love seeing
where everybody's from.
We've got Lassa, I hope I'm pronouncing that correctly,
from Copenhagen, Denmark.
Welcome.
Matt says Pennsylvania, yes, excellent.
Thank you, Matt.
John Chicago says hello.
Welcome, John.
All right.
Excellent.
So today we are going to be chatting about a little tool
called the Create Block Tool.
Adrian says, "Even Americans don't know that much
about other parts of our own country 'cause it's so large."
Yes, something that I discovered on my first trip to the US.
Traveling from one state to the other state
is literally like an international trip in Europe.
That was very interesting to me.
Okay, as I was saying,
so today we're talking about a tool called Create Block.
Create Block is a JavaScript tool
that allows you to generate your sort of first block
or a block project, a new block project.
And I like using tools that scaffold code for me.
So whenever I'm starting a new block project,
I reach for create block and I scaffold the code
into a new project and then I'll maybe rip some of that code
out and put it somewhere else and move things around.
But I tend to use it quite a lot
when I'm working with blocks.
But before we dive into the workshop today,
let's just handle a few announcements.
So first of all, again, welcome to everybody
who is joining us today.
And also thank you to Tracy, who is co-hosting with us here
today.
Tracy is handling admitting folks and all kinds
of other things.
So I really do appreciate his help for this workshop.
Please let me know if you can't see my shared screen.
So right now, you should see a slide that says Announcements.
If you can't see that, please let us know in the chat.
And then I'll just re-enable the screen share,
and that should sort out that problem.
We are presenting in what's known as Focus Mode.
So that means Tracy and I can see all of your video,
but you can't see each other.
This just prevents anybody from zoom bombing the session
and making it awkward for other folks.
You are welcome to enable your video if you would like to.
You're welcome to disable it as well.
I don't mind either way.
But it is nice to see folks on screen who
wave like Adrian does, like Jim does.
So I thank you and I appreciate that.
There is-- when I first started teaching adults,
it was in a martial arts class environment.
And there is nothing more difficult than the faces of adults after a long day of work
who are sitting there while you're teaching, who really don't necessarily want to be there,
but they're there because they feel the need to be there. So I do appreciate your faces
and seeing your interactions. So thank you for those that do enable, but as I say, no
requirement from anybody. Welcome, Mark from Issaquah. Good to see you again. And as always,
you are welcome to ask questions at any point in time, really. You're welcome to post them in the
chat or unmute to ask questions. The only thing that I do ask is if you want to unmute to ask a
question, please, if it's not specifically related to what we're talking about that time on screen,
please keep it for the breaks that I do make as we go through the session. Cool. Then a few more
announcements. So this is an update to a previous workshop. I have run this workshop on the Create
Block tool before. And the reason for that is there have been some changes to Create Block over
over the course of the last year, roughly.
So I'm gonna go through some of those changes,
some of those additions today.
The last time I did this, I also had a whole section
on all of the software you are required to install
before you can use CreateBlock.
Since then I've created a tutorial on that,
on Learn WordPress.
I'm literally just gonna link to that tutorial.
And I did link to it in the Meetup group description as well.
So we're not gonna cover the requirements,
we're just gonna briefly go over them
with a link to that tutorial.
If I'm going too fast, please do let me know.
We will be recording this session and posting it to WordPress TV afterwards.
So if you need to leave or if you're going to catch this up later, it will be online.
And then as always, if you're looking for more learning resources,
you can find those at learn.wordpress.org.
It's where all the workshops are listed.
There's a workshop calendar you can subscribe to.
It's where all the tutorials that we work on are listed
and it's where all the lesson plans are listed, as well as all the courses.
So that's where all our learning resources are.
And then finally, the new developer blog, developer.wordpress.org/news.
It's a fairly recent, well, I probably need to stop saying fairly recent,
because it was launched earlier this year.
So by this time next year, it'll be old hat.
But it's a great place to catch up on how to use tutorials and blog posts
around developer-focused content.
So do go and check that out.
Then our learning outcomes today, as mentioned,
we're going to be looking at the Create Block tool.
We're going to look at what it is and what it can be used for.
We're going to look at very briefly the requirements,
and then I will link to that video with you
that you can watch afterwards
if you haven't installed those requirements.
And then I'm gonna show you how you can use
the Create Block command line tool
to scaffold a new block plugin very quickly.
We're then gonna review the structure of the plugin
and how it works.
And then I'm gonna look at some of the newer options
that have been made available to create block
since the last time I did this workshop.
So there are some switches that have been added
to the command line tool
that allow you to do different things.
So we'll cover those.
All right, before we dive in,
Quick question time for everybody.
So in the chat, please let me know on a scale of one to five.
One being you don't know much at all about Create Block.
This is the first time you've heard about it.
Five being you are scaffolding blocks like a,
I don't know what the term would be,
but you know what Create Block is.
You use it multiple times.
You know exactly what it does.
Just give me an idea in the chat where you are
and we'll see where everybody is.
Okay, so I'm just scrolling up here.
So Jim is a one, Laura is a one, Adrian is a two,
Mark is a 2.5, Miltal is a one, Tim is a two,
Matt is a three, Robert is a three, John is a one,
Andrew is a two.
- Bartinga reminds us all that
South Africa versus Australia.
Cricket is going on, if you know.
And my son was watching that earlier.
He's actually at cricket practice now
and he was watching the game earlier.
So that is going on right now, the World Cup cricket.
Lasse says he's a two, Mark is a two, Robert's a two,
a couple of ones, shoulders are two, a few more ones.
Okay, so we've got a nice range of folks today,
which is great.
Hopefully for those twos and threes,
there will be something new here today.
So we're not gonna be diving into how to create blocks today.
This is just sort of the first step of scaffolding
your first block using the Create Block tool.
I have done other sessions on building blocks.
There are courses and tutorials
on Learn WordPress on Building Blocks.
There's a course that I'm actually,
I've just wrapped up that I'm probably going to release publicly
on building your first custom block that uses the Create Block tool.
So today we're just going to be focusing on the tool
and how it works and what it does.
All right. Then let's move ahead.
So let me share a link with you quickly in the chat.
Before I do that, I just want to check if anybody has any questions
at this point in time.
If you're welcome to post your question
or share your question if you like,
while we open up this link.
And then I also want to share this link with you.
So open that up, and I'll paste that in the chat for you there.
All right, we don't seem to have any questions,
so I think we're good to go ahead.
OK, so the first thing that I shared with you
is the package reference guide for the WordPress
Create Block package.
It is the-- as it says in the documentation,
It is the officially supported tool for scaffolding a WordPress plugin and a block.
Now there's a lot going on in that sentence, so let's chat about that.
What do we mean when we say scaffolding? So scaffolding is a term that is used in software
development realms, it's a building term that's been borrowed, and it means something that
generates some foundational code for you. If we think about scaffolding in the building world,
you generally when you're erecting a building, you put the scaffolding up so that folks can work
on that building and then the building gets built
with inside the scaffolding and then often the scaffolding will get taken away.
And what's left is just the building, the final book thing.
So often your scaffolded code is just your example code, if you will.
It's the initial set of code that you can use to build something on top of.
A lot of the time, the scaffolded code that you would have generated using a tool
will get completely replaced because your requirements are different from what the tool generates.
The second thing that I want to focus on is the use of the term plugin.
Now, it's not a requirement.
You don't have to register your blocks in a plugin only.
You can do your block registration in a theme if you would prefer.
The only time that becomes super, super important is you can't at the moment,
and this might change in the future,
but at the moment, the WordPress themes directory,
So the official themes directory that WordPress.org manages
doesn't allow blocks in themes.
The theme review team believes that block functionality
is plugin sort of realm.
And so blocks should be within plugins.
If you've been following some recent discussions
around this online, there have been some discussions
around whether that should still be like that moving forward.
As I say, it might change in the future.
But for right now, if you're building blocks,
it's generally in a plugin.
But I will show you later what we're doing and how you can then take that over to a theme if you would like to,
if you're building a theme for clients or for any kind of other plugin directory or theme directory, other than WordPress.org.
Then the next instance that says there, it generates the PHP, JavaScript, CSS code and everything else you need for a block project.
And it also, the third sentence there, it says it auto, it also integrates a modern build setup with no configuration.
Now, the important thing that I want everybody to remember is that using create block is not the only way that you can register blocks.
And the code that create block generates is not the only way that you can register blocks. There are multiple ways of doing it.
Using create block follows using React,
which is a JavaScript framework,
which is what the block editor is built on.
It uses what's known as JSX,
which I'll share with you in a second
when we look at the scaffolded code.
It uses more modern JavaScript,
so it uses things like imports
and various other things like that
that you may not have seen before
if you haven't worked with those tools or those frameworks,
but it's not the only way.
it is possible to build blocks using just plain vanilla JavaScript.
I have actually done a series of workshops on that,
which I think might be useful to share.
So I'm going to find that blog post on my blog quickly.
Am I going to find it now? No, probably not.
So let's just do a search for it here.
So all of these workshops were hosted on the Learn WordPress Meetup group.
I just linked to all of them in this blog post.
And in this one, I create a very simple plugin
and I don't use any React, any JSX,
any build steps or anything like that.
And I dive into how that works.
So that's the other way that you can do it as well.
So there are multiple ways of doing it.
You don't have to do it this way.
What I like about Create Block
is if you've never worked with the modern JavaScript before,
you want to kind of start learning how it works.
It's a great way to dive in.
It also uses the block.json metadata file,
which is a lot easier to manage than registering the attributes
in the block registration function, for me personally, at least.
And it gives you a nice directory structure for your source directory.
So your edit component is in its own file,
and I'll describe what those things are when we get there,
if this is all foreign language to you.
Your edit component is in one file, your save function is another file.
Your editor style sheet is in one file,
your front-end style sheets in another.
Your block JSON is in a third place.
So making changes to any one of these areas, I believe,
or I feel at least is a lot easier
when it's well structured.
So that's why I recommend this tool.
This was a tool that I wish I had
when I started learning block development.
I learned block development by teaching myself React
from a course about React,
and then taking someone else's block plugin
that had similar functionalities to what I wanted to build
and sort of reverse engineering that plugin,
'cause it was an open source plugin.
There were a lot of things that I did there that were just copied from the other developers code
that I've now realized could have been done better or easier, whatever the case may be.
My recommendation today when somebody wants to learn block development is to learn how to use
create block and then learn how to understand what create block is scaffolding and how those
things work and then go from there. All right, any questions on that before we move on to
the requirements which I will pop up in the screen share while I refresh my voice.
You can always tell when it's warmer for me because I stopped drinking coffee and switched to
water. It's so much easier to drink water in summer. All right. So your requirements for using
create block are actually only the first two requirements on this list. Number one, you need
a working terminal to run commands because this is a command line tool. If you are in a Mac OS
environment, then you have a built-in terminal. This is what my terminal looks like over here.
I have a light mode because I like light modes. Apologies to folks who hate light mode,
but that's my personal preference. Mac OS has a built-in terminal. Most Linux operating systems
have a built-in terminal. Windows is the one that many, many, many years ago didn't have the best
terminal in the world. It was the command prompt. It didn't really work very, very well. But since
then Windows has come a long way. And my recommendation now is Microsoft has something
called PowerShell, which you can go to microsoft.com/powershell. It actually just redirects to
learn.microsoft.com, PowerShell.
And PowerShell, it's not exactly the same
as a Linux or Unix style terminal.
But if you install PowerShell, you
get a lot more sort of Unix-y like environment
to run commands.
Then the other thing you need to do
is you need to install Node.js and npm.
So I'm going to open up the Node.js and npm home page
quickly. To share that link with you in the chat. Apologies, Matt, for forcing you to
squint there. I could go off on a tangent on this, but there's some research around the
benefit of light themes. If you would like to read it, I might share with you online somewhere.
So Node.js is this piece of software that was developed I think around 2008, 2009. I'm not
exactly show the date. But basically it was when JavaScript started becoming more and more popular
as a development tool for the web. So there was a stage where JavaScript was kind of really just
used to make things look interesting, to animate things. Ajax requests were sort of very limited
in what they did. And as JavaScript developed, this JavaScript developer, some way I can't remember
exactly where he was, wanted to be able to run JavaScript on his machine instead of just in the
browser. Just like you can run a PHP on your machine, you can create a PHP script and then use
the PHP CLI to run PHP on a local machine. He wanted to do the same with JavaScript.
He developed this thing called Node.js. This opened up a whole world of things that you could do with
JavaScript. Whereas before JavaScript was just this language that you used in a browser,
now you could use it to create executables, essentially. You can create code that will run
on your machine, you can create code that will run on the web, there are servers that run in
JavaScript. Whether or not that should happen is a whole different conversation and not one that
I have an opinion on, but it does open up a lot of functionality for JavaScript developers.
There are multiple ways to install Node.js on your local machine, and there is a video that I'm going
to share with you now, we're not going to watch it, but there is a tutorial, sorry, I've just messed
I messed up my link here.
There is a tutorial on Learn WordPress
where I dive into my suggested recommendations
for installing Node.js and NPM for the first time
if you have never done it before.
You're welcome to go and watch that video
when you have some time.
Essentially on macOS, it's a case of installing NVM,
which is something called the Node version manager.
And then once you have NVM installed,
you can then install Node.js from there.
In Windows, I recommend a package called Chocolaty,
which is a package manager for Windows,
which allows you to then install NVM,
the Node version manager,
and then from there you can install Node.js.
There is also at the bottom of this tutorial,
there is also for Windows folks,
there is a NVM Windows management utility
that you can install, that's another option.
You could just also install it from the Node.js website.
But ultimately what you want to be able to get to
once you've got it all installed
is when you open up your terminal,
you want to be able to run the following two commands.
So the first one is node minus v,
and that'll check that node is installed
and show us what version is being run.
So in my case, I have version 18.16.1,
which if we have a look as the current,
or 18.18.1 is the current LTS I need to upgrade soon,
but it's close enough.
When you install Node.js,
it also installs something called npm,
and that's one of the reasons why I shared this link with you.
So NPM is actually two things.
And personally, I'll be honest,
I hate it when multiple things have the same name
'cause it makes life confusing.
But NPM is two things.
NPM is both a command line utility in your machine
once you install Node.js,
as well as a repository for JavaScript Node.js packages
that other developers are working on
that you can download and install.
So if we go to, I just want to see if I get a list of the packages here.
Let's see if I got, no, let's just see if we can just search for WordPress, for example.
So if I search for WordPress here, if I could spell it properly,
this is the list of packages that exist around the WordPress.
I can use npm and therefore Node.js to install and use any of these packages
on my local environment.
If you've never worked with any kind of package dependency manager thing,
Composer is another good example.
So Composer is a package manager for PHP,
NPM is a package manager for JavaScript code.
So once I have Node.js installed,
it will also, sorry, I'm just moving
this video thing out of my way here,
it will also install NPM.
So when I know that Node is installed,
I can also run NPM minus V,
and then that will allow me to check that I have NPM installed as well.
When I can do those two things,
Now I'm ready to start using the WordPress Create Block tool.
And the reason that I need those things is because Create Block,
as I shared with you in this link,
let's go back two steps,
is a package that exists in the cloud in the NPM package repository.
So while the first link that I shared with you is the documentation for NPM,
this is the actual package homepage, if you will, on the NPM package manager.
You will see that the documentation is pretty much the same.
They've just copied it over to the two places.
But this will show you things like downloads,
this will show you the home page,
it'll show you how to install the package
if you want to install it,
and various other things about the packages.
You'll see this is very similar to the plugin homepage
for plugins on WordPress.org.
So essentially it's the homepage of where the software lives
and I can then use it.
Okay, any questions on, no problems James,
any questions on all of that,
any questions on the requirements,
any questions on the package manager side of things
before we dive into how we can use this.
I hope your dental appointment wasn't a painful one, James. Mine usually are.
Good question, Laura. Laura says, just to clarify, you don't need to download a separate file for NPM.
It gets created with downloading Node.js. Absolutely correct. When you install Node.js,
NPM comes with that.
The reason-- and that's actually a good question.
The reason I have both in the title for this tutorial
is because often folks who want to use Create Block,
for example, they will see that they
need to use an NPM command.
And they will then think that it's
something separate from Node.js.
But yes, they do become packaged.
So as long as you install Node.js,
then that will install NPM as well.
To the best of my knowledge, there
are no Node.js installations that won't also install NPM.
It's kind of part of the package.
So good question.
Thank you for that.
James says, "Nope, I love the dental tier.
I'm on."
(laughs)
I wish, yes, I wish I had a dental tier
for my homework setup.
Yes, I agree with that one.
Those dental tiers are comfy.
I want the one that my dentist has with the TV above me.
(laughs)
Okay.
Tracy says, "Does the Create Block process
require specific versions?"
That's a great question, Tracy.
So you will notice in the,
and I'm gonna be focusing on the WordPress documentation
because the NPM documentation for CreateBlock
is exactly the same.
So I'm going to close that one now.
And I'll close this blog post.
I'll close that and that and that as well.
You will notice if you scroll down to the Quickstart area,
it says there requires node version 14.0.0 or above,
which therefore will be NPM version 6.14.4 or above.
So that's the minimum sort of base version you need.
As you may have seen earlier, Node.js currently
is running what's known as the LTS, or the long-term support
version is currently at version 18.
So if you install Node.js brand new clean from now,
you will get version 18 or higher,
and you don't have to worry about version requirements.
If you have already installed a previous version of Node.js,
maybe, and I think version 14 was about,
let's say four or five years ago was version 14,
then you might need to do an update.
And Node is actually,
as someone who's used both Composer for PHP packages
and NPM for JavaScript packages,
NPM is actually, I believe, a lot better
in rewarding you when it needs to be updated.
And when you run an NPM command,
like we're gonna do in a second,
if you aren't running an updated version,
it'll actually say, hey, you need to install Node.js and NPM,
but it'll actually give you the command to do it.
So yes, at the moment version 14 is the minimum requirement,
but most folks who install Node.js today
will get an updated version.
Okay, James, just for the first package steps,
there is actually a full tutorial on Learn WordPress
that you can watch.
I specifically don't cover it in this workshop,
but here is the link,
so you can go and watch that at your leisure
and that'll give you all the details you'll need.
All right, cool.
So if we go down to the quick start,
and that's where we get,
I'm glad that Tracy's already taken us there
'cause we're already there on screen.
On the quick start page,
I'm just gonna pop this in the chat as well
for those who have joined us later.
There is a section, if you scroll down a bit,
that says quick start.
This is essentially the command you run to create your plugin.
So let's dive into what this command does.
So you'll see that it says, instead of NPM, it says NPX.
So NPX is a special version of NPM that is installed as well
when you install Node and NPM that allows you to both
install the package in your local package cache,
if you will.
So it's not per project,
it's sort of stored in a more global area.
Download the package and then run the package.
So that's why it's NPX, X4, execute.
So it's kind of like we used to,
and we still do today,
we install some software on our machine
and then we run the app file or the executable file,
NPX is essentially one way to do that.
So you will notice on the,
let me go back one step.
I wanna show you some slight differences on the NPM page.
You will notice on the NPM page,
the way it says to install is to run NPM I WordPress
create block.
So that will install it in wherever you run that command,
but then it won't run create block.
So you could do NPM minus I WordPress create block,
and then you could run and create blocks separately,
or you can just do the one command,
which is the npx command.
And that's the recommended easiest way to do it.
The nice thing about this command is you'll notice
it also has this at latest appended on the end.
What that does is that will check
if the version that you have installed globally
the last time you ran this command is up to date.
And if it isn't, then it will simply install
the newest version.
So that's why it's a great way to memorize this one command
and then you just have to run it every single time
you want to use create block, and it'll just always work.
And then the third option is here
is what we call the plugin slug or the block slug.
And that is the minimum piece of data
that create block needs to scaffold your plugin.
The slug is what will be used
to create the plugin directory.
So I'll show you in a second what it creates.
It'll also be used to create, to give the block a name
and various other things that it needs.
and the rest that will accept defaults
for all of these options that it has.
Some of the options we'll dive into later,
I'll show you how you can customize it for yourself
if you want to, but for now, this is the easiest way to do it.
So I'm going to copy out this command.
I'm going to open up my terminal
and I'm going to change directory or CD
and CD should work across all operating systems.
CD is a common command for changing directory.
And I'm going to go to my local WordPress environment,
which is not that one, it's that one.
I have my environment set up in that directory,
wplocalenv.
I have a sites folder,
and then my site that I'm gonna work on
is called LearnPress.
You would obviously change that
to whatever your local site environment is.
So when I change it to that site,
there's a command you could run called ls -lih
in Unix environments,
so I think it's dir/w in Windows environments,
and you will then get a list of all the files sitting there.
So here you'll see is my WP content folder,
my WP config should be somewhere, there it is,
and all of those WordPress files.
Then I'm going to want to change the directory
to my plugins directory.
So that is simply CD, WP content, and then plugins.
I could have just gone local ENV sites
learn press WP content plugins if I wanted to,
that's another option,
but I like to kind of break it down in steps.
So this is my plugin directory,
And you will see that I have some plugins
that I've installed, FakerPress, MyReadingList,
which is a project that I'm working on, SQL Buddy,
which you've probably seen me install in previous workshops,
and then other plugins we've worked on.
And so to clarify and to verify that that is the same,
here is my LearnPress inside of my Visual Code Studio.
I'm gonna make this a little bit bigger.
There is my content, there is my plugins,
and there's all the same files.
So I create block theme, FakerPress,
so we know we're in the right place.
And then I'm just gonna use the clear command
so that everything's nice and clean again.
Now we can run the NPX at WordPress/creates-block
at latest and then give it the slug.
What I like to do, I'm trying to paste that in the chat,
what I like to do for these workshops
is I like to prefix my slug with a WP hyphen
just because that's something I do and then the word learn.
So that just gives it some uniqueness.
So let's see what this is going to now generate.
While that's working, I'm going to answer James' question.
So James says, "Sorry, just checking
are you using WPC-LI commands tools?"
No, James.
I'm glad you asked that question.
So this is specifically node.js and npm command line tools.
If you watch the beginning of this recording,
I do dive into that and what node.js and npm is.
And then also if you go watch that tutorial,
I dive into that as well.
But this is unrelated to WPC-LI.
There was some talk, I think,
of actually creating a WPC-LI command
that would run the npx WordPress create block command.
I don't know if it actually ended up becoming a thing yet.
It would be cool if it did,
because then folks that are comfortable with WPCLI
would be able to use that.
But at the moment, this was purely just using npm, node.js,
and all that.
Right, Mark has a good question.
To confirm, you should always run this
in a WordPress environment plugin folder.
And the answer to that is Mark, no,
you don't have to run it in a plugin folder.
it's going to create a plugin folder for you,
which you can then copy into any WordPress install
you want to, but there's nothing stopping you
from running it anywhere else.
I used to, many, many moons ago,
I used to have a single WordPress install,
and then I used to have a separate development directory.
That, and it's the reason I had a separate
development directory is because I used to be working
on a plugin and a Laravel app at the same time,
and I wanted them in the same place.
So I had the plugin and the Laravel app
sitting in the development directory,
and then I would some link the plugin from the plugin,
sorry, from the development directory
to my WP content directory from my WordPress site.
So that was one way to do it.
So no, you don't have to run this
inside your plugins directory.
If you want to see it working, it's just easier if you do.
'Cause then it's inside your plugins directory,
you can just activate it and you can use it
because what's generating is a plugin.
James says, I was about to say,
it'd be nice to have that merged in WPCL.
Yes, I seem to recall a conversation around it
at some point, but I can't remember
whether it did actually happen or not.
I think maybe the reason it didn't happen
is because you would need to have NPM and Node.js installed.
So just having it as a WPCLI command
means that that command would have to install that software
and that adds some complexity,
but that might be a reason why it hasn't happened yet.
Okay.
So as you can see, this is doing some work while I'm chatting.
And that's why I'm so glad that folks ask questions,
because it takes a while sometimes for this to happen.
But you'll see the first thing it does is creates the new
WordPress plugin in the, let's, okay, it's finished now,
but let's scroll up.
It creates the new WordPress plugin in the directory for us,
the WP Learn to Do list, which is the one we sent it there.
It creates the block.json file,
it creates the package.json file,
Then it installs what's known as the WordPress scripts package,
which I'll chat to you about in a second.
It then does some formatting of JavaScript files,
and then it compiles the block code.
Then it says done.
WordPress plugin, wplearntodo is bootstrapped
in the wplearntodo list directory.
And then it tells you there are certain commands
you can actually run.
So you can run npm start, run build, run format,
and various other things you can do.
I'm not going to dive into those too much today.
Into the directory, you type in CDWP learn to-do list,
and to start development, you write NPM stock.
Don't worry too much about that right now.
Let's first have a look at what this created for us.
In my plugin, I now have here WP learn to-do list.
That was just created, this one I created the other day.
But you'll see I specifically named it
WP learn to-do list for our purposes.
Inside of WP learn to-do list, we have the following.
We have a bold directory, we have a node_modules directory,
we have a source or SRC or source directory.
Then there's an editor_config and get_ignore,
which we'll chat about in a second,
a package.json and a package.lock.json,
a readme.txt and a PHP file.
In this case, wplearntodolist.php.
So let's go into the comfortable areas first, the PHP file.
If you are a plugin developer, this code
will look very, very familiar.
I'm going to make it a little bit bigger so that it's a little bit more visible on screen.
Oh, wait, not scroll, plus, there we go.
So this is a standard WordPress plugin.
It has the plugin header at the top with the plugin name, description,
that requires at least number, requires PHP, version, author.
If you've worked on plugins in the past, you've seen this before.
Then the second bit of code is also very familiar.
It hooks into the Annette action hook, so using the add action function,
registers the create block WP learn to do list block and net callback.
And then inside of that callback, it calls the register block type function,
passes in the dir constant, which means the current directory,
and concatenates that with the path to the build directory.
So that is this directory over there, the build directory.
What register block type does is it receives a set of information about your block
and essentially tells WordPress, "Hey there, here is a new block that you need to be aware of.
Here is all the code for it, but you just need to, when you load the editor,
make sure you load this block."
So let's go and have a look and see what's inside the build directory.
Now, the great thing about create block is when it runs the first time,
it automatically runs what's known as the build process
and generates the code in the build directory.
This is the code in a modern JavaScript environment that is what runs when the editor loads.
So there you will see there is a block.json file.
This file is your block metadata.
It includes things like the API version number, the name of the block, the version number for the block,
the title, which is the title that appears in the block editor,
what category it belongs to, and various other pieces of information.
I'm going to share some documentation with you so you can go read up more about what that all does.
If we go to the block editor, that's a good place to start.
And then if we search for metadata.
There we go.
So that will give you all the information you need about what the metadata does and how it works.
Then we'll notice that it also has these properties at the bottom here.
It has an editor script file,
it's a style, style, and view script.
Editor script is the main JavaScript file that powers the block.
Original source code, which I'll explain in a second.
But basically when the block editor runs and this block is loaded in the editor,
this is the JavaScript code that runs.
I'm going to format it a little bit better for our purposes
so we can see what it's doing.
Actually, it's not going to format because of the fact
that it's transpiled.
But basically, this is the core functionality for the plugin.
Then there is the editor style file.
And this one is pointing to the index.css file.
So let's open up that.
And this is very familiar.
So this is CSS that's being applied to this class,
the WP block create block WP learn to do list,
recognize the name, and it's applying some CSS for us.
This was scaffolded by the plugin.
All it does is put a red border around the block.
Then the next one is the style file,
which is the style-index.css.
This is this one over here.
That does some slightly different styling,
but it's applying it to the same class.
To understand what these two files do,
the index.css is what loads in both the editor
and on the front end.
when this block loads, when this block is either loaded
in the editor, or when it's rendered on the front end,
this CSS loads.
The style-index.css only loads on the front end.
So if you have a situation where you want specific functionality
to only look a certain way in the editor
and you want it to look differently in the front end,
then you would use the style-index
to style the front end.
The only time I've ever used this
was one of the first plugins that I developed
was a episode selector plugin for the podcasting plugin
I was working for.
Sorry, episode selector block.
And what we wanted users to do
when they added the block to the editor,
it showed a dropdown of all the episodes in their podcast.
They clicked on the dropdown
and then they selected from the dropdown the episode.
Once they selected the episode, the block refreshed
and actually rendered that episode player in the editor.
So the final render of the episode player
needs to look the same back end and front end.
But the dropdown only exists in the editor,
because you're not going to show the dropdown to any users
on the front end.
And the dropdown only needs to style.
So the dropdown styling I left in the index.css,
I put it in there, but I left it out of the style.css.
That's the only time I had to think about those two places.
Generally, you can get away with only using your index.css,
especially if your block looks exactly the same on the front
end as it does in the editor.
And then if you're only using that index.css,
that it's a style, you can remove this property,
excuse me, from your block.json file
and remove the original source code that generates it.
And then finally, there's this view scripts.
This is a fairly recent addition
to what create block scaffolds.
This is simply a JavaScript file that loads
when the block renders on the front end.
All this file does in the scaffolded version
is just console, log something to the console.
So this is if you need your block to do something different
when it loads on the front end,
maybe some animation or something,
and it mustn't happen in editor,
then you can use this future.js.
Again, if you don't need that functionality,
you can remove it from your block.json file,
and you can remove the file from your source directory,
not your build directory.
And this is the important part I wanna wrap up with
before we take a break.
Your build directory, you never make changes to.
The build directory is rebuilt every time
the build server runs or the build process runs.
We'll talk about that right at the end.
Everything that you want to make changes to
is inside of your source directory, or SRC in this case.
All right, any questions?
I'm going to check if there are questions.
index.css and style.index.css seem badly named to me.
I wonder why they are named like that.
Honestly, it's really just what the block scaffolds.
You can call it anything you want to.
As long as you have set up the style property
to point to that file, it'll work.
And I'll show you--
actually, no, I think I'm talking--
I'll show you in the source directory in a second
how it works.
But essentially, as far as I know,
this is kind of a--
it's either a WordPress or a Webpack-related thing
that automatically builds those files.
So it's kind of a formalized version of it.
But in your source code version, you can call it
whatever you want.
And I'll show you that in a second.
All right, before we move on to source,
let's talk about node modules.
Node modules is where all the dependencies for your project exist.
So when I talk about dependencies, what we mean is for a JavaScript project
that is using a framework like React, it uses other bits and pieces of software
that other developers have wrote, written, that performs certain functionality.
A good example of that is if you're building a PHP plugin or a PHP something,
you might want to be able to do like a REST API request.
you might want to use some code that exists elsewhere.
You can include a dependency and you can use it.
So because React is built around this framework
of relying on other dependencies,
the node modules is where all those dependencies sit.
Node modules, you never package with your final block plugin.
It's only a development tool.
And so when we dive into the git-ignore file in a second,
you'll see it's actually excluded from the git-ignore.
Node modules is another thing you never make changes to.
And if you ever have problems with your dependencies,
the easiest way to fix them generally
is to nuke your node modules and then run npm install
inside the project again and let it reinstall all those dependencies.
Okay.
So while we're talking about dependencies,
let's dive ahead quickly to the package.json file.
The package.json file is an npm thing.
And it basically is the file that manages the project,
not the block itself, but specifically the project.
And you will see we have one dependency,
and that's this WordPress scripts dependency.
WordPress scripts is what is being depended on to work in this project,
and it is installed inside this node modules directory.
WordPress scripts then depends on all of these other things
that are inside of node modules.
That's why it tends to get very big.
But in the terms of the block plugin,
the only one that you have to use to get a basic block plugin to work
is WordPress scripts.
The other important part to understand is the scripts property here.
you will see it has build, format, lint, lint, package, update, plug-ins, zip, and start.
These match up to the commands that were mentioned in the front here. And this is how you're working
on building blocks. And I'll show you a live version of how I'm going to make a change to
the block and how we build the server to be able to make your final build code.
Okay. Barinja, I see your question about GraphQL. I'll get to that in a second.
Okay, then finally, let's talk about your source directory.
So this is where you'll actually do your work.
So let's close all of this down and let's look at what's in the source directory.
So while this register the block type on the build, the source is where you do your work.
And it's actually the SRC directory, but I call it source because it's short for source.
Inside the source directory, you have again the block.json.
And you'll see that these are all the same as what we saw in the one in the build directory.
When the build step runs, the blocked JSON file is copied as is over to the build directory.
Nothing changes to it.
So that's why we need to set these up like this.
But what happens in the source directory, so let's talk about the style.index, for example.
In the source directory, it's configured to the style.scss file.
You'll see this is not determined anywhere here.
We don't see style.scss anywhere here.
But that is the file and there it is.
There is the CSS, the original CSS.
and there is the original background, color, color, and padding.
If you've never seen an SCSS file before,
it's what's known as a syntactically awesome style sheet file.
It's something that was originated a number of years ago
as sort of an advanced level of CSS.
It allowed a lot of things that CSS then couldn't allow,
like nested CSS and CSS variables and all kinds of other things.
But syntactically awesome style sheets also support regular CSS.
So if you're used to just regular old vanilla CSS,
you can write that in here as well and it'll work.
So that's the one for the front end.
The one that renders in the backend is the editor.scss.
So here it's a bit more of a mock, as you can see,
it's a bit more logically named for where it works.
So the editor, the CSS is for the editor,
and the style is for the front end.
And as I say, I think this naming here
is either based on the way React does things
or the way Webpack does things.
Webpack is what runs underneath the build server.
I'm not sure 100% which.
But in your source, this is what they're called.
In your source, you also have an index.js file, your main index file.
And this is where the original sort of block code starts working.
So you'll see here we import the style.css.
So that's our front-end style.
Sorry, the front and back, sorry.
We import the edit component from the edit file,
which is this one over here.
We import the save function from the save file,
which is this one over here.
and then it says every block starts by registering a new block type definition.
And you'll see this function here register block type is very similar to the PHP one we saw earlier,
but it does two different things. As I mentioned the PHP one says hey WordPress editor,
here is some block code for a block. Use it, that's all it does. This one now actually registers
this block so when the editor loads, if the PHP runs hey here's a block, editor goes cool,
I see where your block code is, but now I want to register the block in the editor.
And that's where this register block type function is called.
You'll see that we import the metadata from the block.json file.
So that imports all of those, that JSON object into the metadata variable.
And then we use the metadata name to register the block type.
And then the block type has certain properties as well.
The two primary ones you need to worry about are the edit property,
which is what happens, guess where, in the editor.
and then the save property, which is what happens when the block saves its output.
So let's go and have a look inside the edit.js. Inside the edit.js, this is all the functionality
that happens in the block editor. So it does some more imports. This is kind of diving into
how the block editor works. It imports the editor.sss file. And then here, this is the key part. This
is the function that does whatever this block does in the editor. So in this case, it just says,
It says wplearntodolist hello from the editor.
It has some use block props going on
and whatever else, it's got these paragraph tags.
And so if I activate this plugin in my WordPress instance,
which I'll do once we've gone through everything,
then I will see that in the editor.
Then in the save.js,
it also imports some packages from my dependencies,
and then it runs a similar set of code to the editor.
This case, it just runs the hello to-do list
from the saved content.
So what I would like to do now
I'd like to make two small changes to the edits and the save.
Inside of the edit function, and those of you who have used JavaScript
will probably recognize the use of console.log.
I'm just going to console.log/edit.
Why is it not all copied? There we go.
So that you can see every time the edit runs.
So you'll know if I open up Developer Tools
and I load the block into my editor,
we should see this code run.
Then in my save.js, I'm going to do exactly the same thing.
I'm going to say console.logSave.
Come on, there we go.
Console.logSave.
All right.
Now I've made some changes to this plugin code.
But until I run the build step, those changes are not going to take effect.
I want to show you, however, how the plugin looks currently
and why it works currently before we make these changes.
So let's load it up in a WordPress instance.
If I go over to my local WordPress site,
and I log in, which I probably should have done before we started.
And I go to my plugin directories, my plugin list, should I say,
and let's go and find this to-do list, WP Learn to-do list. There we go. Let's activate that.
And at the same time, I'm going to open up my developer tools so we can see what's happening
in the console. There we go. And then let's go and create a new post. So we'll say add new,
And I will simply add the learn to do list.
WPLearn to do this.
So you see there's a little smiley there.
That's because the smiley is defined in the block JSON.
That's the title that's defined in the block JSON.
So there we go.
So now you'll see in the console, I don't see the word "init"
because I haven't rebuilt those files.
But I do see the final code.
So why has that happened?
That's because-- wait, where are we?
No, it's got all the way through my things.
That's because the first time this plugin was run,
it ran what's known as the build step
and it created the build directory.
So that's why the plugin is working.
If I delete this build directory, which I'm going to do,
so I'm going to delete the build directory
and I try and load this in the editor,
let's actually remove that and let's refresh.
And I try and add.
learn to do, there is no option.
Because while I'm minded with a PHP code
said to WordPress, "Hey, here's some plugin code,"
I deleted that build directory. It doesn't exist anymore.
So I need to do what's known as running the build step.
Now, there are two ways to do this.
The first way, if we go back to the commands that they gave,
the first one is npm start, which starts the build for development.
So this is something you can run while you're working on your code.
And it'll just keep it-- it runs something called a file watcher.
It's a software package called Webpack that runs underneath it.
And basically, it just watches the project,
and it checks for any changes in the source directory.
Once those changes are made, it rebuilds the build directory.
So let me show you that in action.
So I'm going to remove the console logs for now.
Actually, let's just take them out completely on the save.
Take it out completely on the save.
You'll see there's no build folder there.
I'm going to switch back to my terminal,
and I'm going to run npm start.
And that's because I'm not in the plugin directory,
so let's log into the plugin directory.
Sorry, not log into, change directory to the plugin directory.
There we go.
And now I can run npm start.
And the reason I can run npm start
is because inside of my package.json file,
there is a script called npm start,
and that runs wp-script start underneath.
So that's why this works where it does.
So let me get back to my terminal and run npm start.
So it runs and it checks and it sees the index and it builds and it sees the view and it
does all the things it needs to do and then it says compiled successfully and then it
waits.
You'll notice the terminal doesn't close, it doesn't go back to the original cursor.
It's now sitting watching any changes I make to these files.
So what I'm going to do is I'm going to split screen right now and I'm going to move this
So let's go back to the Save.
So this is now built, and we can see there's the built directory.
So we know it's going to work in the editor.
Watch what happens when I make a change to the Save file, for example.
All I'm going to do is undo the deletion that I did.
And you'll see it just rebuilt on the left.
Did everybody see that?
It's very quick because this is a very small project.
The bigger your project, the longer it takes.
I'll just go back to the Save file.
And I'll just go back to the Save file.
because this is a very small project.
The bigger your project, the longer it takes.
I'll revert this change so we can see it happen again.
Watch on the left.
There we go. It ran again.
If I undo that, you've seen a couple of things change there.
It's very quick because I'm only making small changes.
But basically, with that file watch running,
anytime you make changes in your source,
it'll just see what changes are being made
and rebuild the build directory every time.
We can actually make it even more obvious
by deleting the build directory.
There we go, so it's not there anymore.
And then watch.
So just keep your eye on the node modules
when I comment out this change,
and you'll see that build directory will get rebuilt again.
There it is. Pop back there.
Okay, so every time you're running that build server,
it just keeps rebuilding.
And that way you can load into your WordPress,
and you can see things work.
So let's do that.
So let me switch back to WordPress here.
Now, because it's run the new build step,
I need to refresh my WordPress instance
so that that PHP code can run again and say,
"Hey, here's the block code loaded in the editor."
It's one of the downsides about building blocks in WordPress.
If you were working in a standard React environment,
you wouldn't have to reload the page,
it would just automatically reload,
but for WordPress we need to.
So I'll refresh the page,
and now I should be able to,
let me just, I don't need the auto-save,
now I should be able to learn to do this, there it is,
and now we should see saves and edits in the console,
because I've added that code.
There we go.
Notice that the save runs before the edits.
And then, see, the save runs again.
So the first time a block loads, it loads the save function.
The reason it does that is it checks
if this block was saved previously, if it was,
what was the data that was saved in this post,
what is the current data being output by the save function,
and it compares the two.
I'll show you what that looks like in a second.
Then it runs the edits to show the edits in the editor.
And then it runs save again to save the new data
to the database.
So that's what that does there.
And now if I preview this, I will also
have this on my front end.
Hello from the saved content.
And there we go.
You'll notice that the styling is not working right now.
Sometimes what happens-- and I've seen this every now and then--
is that the build process realizes
that you're only making changes to the JavaScript code,
And so it doesn't rebuild the CSS.
And because I deleted the build directory,
it just rebuilt the JavaScript code.
So let me show you that very quickly.
If we open up the build,
you'll see there's no CSS files there
because it knows what was built the last time.
And what did I do?
I deleted the directory in between that build process.
So you shouldn't, I mean, you shouldn't do,
as I said, you shouldn't be making changes to your build.
But there's an easy way to fix this.
And that is with the what's known as,
let me go back to my package JSON.
Oh wait, we've got it over here
so we can make this big now.
That is using the build script.
So the build script does everything
that the start script does, but it does it once,
and it builds everything once.
So npm build is what you run when you finish development,
and you now want to build your final version of the project.
npm start is what you want to run when you're busy
in development and you're making changes,
and you wanted to just build the changes to the files
that you make changes to.
Sorry, that's too many changes in that sentence.
So to switch to the build server,
I'm just going to hit Control + C on my keyboard.
That'll take me back to the project folder.
And then I run npm run bold.
Actually, let's clear this out.
NPM run bold.
And that will now bold everything.
JavaScript, CSS, all of it.
If we go back to our bold directory,
we will see that there are all the files.
There's the CSS files and everything else we need.
And if we hop on over to our WordPress environment,
let us remove the block.
Let's refresh the page.
As I said, whenever you're working with blocks,
this is what you have to do.
There it is, the styling is working.
And if we pop on over to the front end,
we get the starting on the front end as well.
Okay, that was a lot of information about create block
and what it does and a little bit of block development
and how block starts.
That is basically the structure that create block sets up.
As I said to you, what I like about it
is in the source directory, the file names,
as Mark noticed, the file names just make so much more sense.
If I'm working in the editor, I'm
working inside the edit.js file, because that's
in the edit function.
If I'm working with the save, I'm working in the save file.
If I'm working with the style that's on both,
I'm working in the style.css.
If I'm working with just the styles that get applied
to the editor, I'm working inside of there.
So that's why I like this environment.
And as I mentioned, if I didn't want to use--
so right now, it's building the view.js.
If we have a look at the build directory,
you'll see there's the view.js.
If I don't need the view.js, I can just delete that file.
And then inside of my block.js, I'll
delete the fact that it's referring to that file.
And then make sure I delete the last comma.
And then if I run my build step again,
or if I'm in development road and I run the build step,
then it'll actually go and it'll ignore that file
next build and there you'll see no Vue.js was created. It manages the build step for me. I don't
have to think about it. I just focus on my source directory and making my changes there.
And off I go developing blocks. Okay. Cool. Thank you, Mark. I appreciate that. It does. What I do
know is that when you first get into block development, if you're still sort of figuring
out how everything works, this is a lot of information to kind of take in on the first go.
But I do recommend using this to scaffold block plugins and start playing with what they do.
The other thing I like about CreateBlock is you'll notice that the developer who created this has
got documentation and links to documentation for every single piece of code effectively.
So it's a great way to go and learn about what that piece of code does.
The first one is importing the internationalization function.
The second one is importing something called useBlockProps, which does a whole bunch of things.
So that's another reason why I love this package, because the code that it generates,
I can learn from as well. It's a great learning tool about how block development works.
All right. Matt says, "Does the tool need to be run each time, or can you borrow code
from previously built blocks?" Yes, you can borrow code from previously built blocks,
absolutely. There is no sort of hard and fast rule. You don't have to use create block to
create a new block plugin every time. You can certainly copy code from other blocks
once you've got them going. The core things that you will need, well, you will need to
to set up the package.json file, because that includes
the dependencies and all the build steps
and all the build scripts.
You will need to create the source directory
with the block.json and the different files in there
and how that's all worked out.
And that's kind of a core of what you need.
So as long as you've got those things,
you should be good to go.
Lassa says, how do you go about CSS caching here?
That is a good question, one which I did not
have an answer to.
There probably is a way to do it.
I think, I stand corrected,
but I think that you would cache the individual files
because I don't think, I think this is just enqueued.
So to kind of understand this,
the JS and the CSS and all of that is enqueued
in the normal WordPress way underneath the hood
using WP and Q and all of that.
So any kind of caching that you would do
been using those functionalities you could do over here.
I don't know myself.
I've never implemented a site where
I've needed to cache the block CSS or the block JavaScript,
but I'm sure it should be possible.
That's actually a good topic maybe for one day
for the future for another workshop.
So thank you for that idea.
I'll definitely dive into that.
What runs the NQ functions?
So because you are using--
let me show you here.
Because you are using register block type,
let's actually see if we can dive into that code.
It uses the block registry, which registers the block type,
which then does everything under the hood.
Yes, you've already answered your question there, Mark.
So yes, it basically is-- all of that
is handled for you under the hood.
But it is possible to use-- there are certain NQ editor
scripts and NQ editor styles functions that you can use.
So if you don't want to use register block type
in the PHP you can go that route.
Personally, I just prefer one line of code
to do it all for me.
But yes, you could do it manually that way if you want to.
Tracy's just, thank you, Tracy.
Tracy's just reminded me of the GraphQL question
that was asked earlier.
So GraphQL is something that kind of runs
separately from blocks.
GraphQL is a type of API that you can use to access data.
So I don't know how that would pertain
to working with CreateBlock,
but I do know that there is a WP GraphQL plugin
that you can use to enable GraphQL on your WordPress site.
And then if you need to access data in your plugin,
you would just need to use a API,
a, sorry, an HTTP package like Axios or one of those
to query the GraphQL.
But that wouldn't, you wouldn't need to worry about,
that's not something that CreateBlock would handle for you.
You'd have to write that code yourself.
You'd have to import that dependency
and then create that code for yourself.
Okay, right.
So two quick things I want to show you before we wrap up
is some of the options that you have available to you
with Create Block.
One of the options that you have
is you can just run npx WordPress Create Block
without a slug.
And I'm going to do that now, so let's just clear this out.
And what this will then do is it will ask you
relevant questions about all the different options
for your block plugin.
So let's make this big again.
So if I do that, it's going to ask me for this like,
it's going to ask me for things like my title,
my icon, what category, all those kinds of things.
It's going to ask me,
do I want to create what's known as a static block
or a dynamic block?
That's a whole nother workshop.
The one we created today is known as a static block.
So I'll use the defaults to static.
It asks me for the slug.
So I would then type in the slug.
I'm gonna leave the defaults for now.
It'll ask me for the namespace.
the namespace is used in the block.json
to identify the block plugin.
And so this will basically is what's called
the interactive mode.
It'll ask you the questions that it defaults by itself
when you just pass it a slug.
In our earlier example, the short description,
the dash icon, the cat's view that it should belong to.
I like the fact that you can use your arrow keys
to choose the cat's view it belongs to.
So that's when it's being selected in the block editor.
Then it says, do you wanna customize your plugin?
So there you can do things like your plugin URL,
your plugin version number, the name of the author.
So instead of having to go and manually make those changes
afterwards, you can do this in interactive mode.
So this is if you want a little bit more control
over what gets generated.
If you're that kind of person.
I am the kind of person I like the single command.
And then once it's generated the code,
then I will go into, for example, my plugin header
and make the changes there.
But other folks prefer to be able to make those changes
right now up front, and this is what gives you that option.
So you can go through and you can do all of those things,
and then it again goes through the process
and will create it for you.
And I'm glad to see that folks are enjoying that option
because it is a really good option if you prefer that.
I'm gonna shut that down now very quickly.
So that's interactive mode.
You'll see interactive mode is at the bottom.
It just says when no slug is provided.
So you just run npx @wordpress/createblock@latus
with no slug and it'll switch to interactive mode.
You can also specify the slug which you've shared,
And then there are some additional options at the bottom.
So you can do things like output a version number.
There's an option where you can say no plugin.
So you don't want the plugin to be created.
You just want the source directory essentially.
And this is perfect if you're building it for a theme.
So let me show you what that does.
So let's go WP, let's go back a step here.
And I'm gonna say WP learn no plugin.
plugin and give it the no plugin option.
And you see this is much quicker because it doesn't need to create the plugin file
and all those kind of things. And if you go into the code editor,
let's go and find WP Learn no plugin.
I can't see it. Where did I do that? I'm inside WP Learn to-do list. That's why. Sorry, folks.
I should have gone upper level. So let's go back. There's WP learn to do list.
And then there's WP learn no plugin. So you'll see all that creates is the block JSON, the edits,
all of the source code is then sitting in that location. And you can then create your own package
that JSON and configure it to work with that if you're working in a theme environment or if you
want to do multiple blocks, that's a great way to do that. So that's one of the other options that
that I wanted to share.
And then there are multiple other options.
You can specify the title and short description
in the category up front.
You can enable or disable WP scripts usage.
You can enable WPEnv.
So if you don't have a local WordPress environment,
and you just want to quickly build a plugin,
you can use the --WPEnv,
which will use a local WordPress environment called WPEnv
and then build your plugin and then load that WPEnv
to start testing.
I've never done that before, but that's an option as well.
Okay, so those are some of the options available.
We could talk about this for days on end.
I just wanted to share this with you.
If you are wanting to get into block development,
if you have never worked on any kind of block plugins
or block development before,
I highly recommend using create block
to scaffold your first few block plugins.
I use it even today when I'm,
so I'm gonna, I don't mind sharing this.
I am taking part in something called Hacktoberfest
at the moment, which is this worldwide open source thing
where folks try and contribute to open source projects.
And I tweeted a couple of days ago,
so that I'm looking for sort of WordPress projects
that are looking to add blocks to their code.
And Joost Efalk from Joost,
I'm sure all of you know Joost SEO,
he's no longer there anymore.
He is busy working on a plugin that does something
and he doesn't have a block for it yet.
And so he reached out to me and said,
do you have time to do this?
And so to work on this, the first thing I'm going to do
is I'm going to scaffold a block using Create Block.
I'm going to build it the way I want to,
and then I will simply port that code,
I will copy that code into this repository
in exactly the same way that I need it to,
because I just find that to be a better way to do things
for my personal style.
So Create Block is a great tool if you're learning,
if you're still developing every day.
What's nice about it is it kind of forces me
into a very structured way of doing things
and working with things which I like.
Structure is good for me because if I'm allowed not structure,
then I go all over the place.
And so that is why I personally prefer to use create block.
All right.
That is my bit for today.
Does anybody have any questions on all of that?
Anything else they want to comment or add?
Please let me know now.
Otherwise, I'm going to sip of water and call it today.
Awesome. It seems that everybody enjoyed today,
so I'm glad that that was the case.
My recommendation to you,
if you don't have no JS installed on your machine yet,
go and watch this tutorial first.
That'll give you some good examples of how to get everything set up.
Especially if you're on Windows environment,
I have found PowerShell and Chocolaty to
be my power tools for when I'm developing on Windows.
If PowerShell and Chocolaty had existed when I switched from Windows to Ubuntu,
I might have stayed on Windows because it seems to make things a lot easier.
Go and check that out if you're learning on Windows.
Once you've got those things installed,
give Create Block a try.
Just see what it generates,
start playing with the code,
start reading about how these things work.
Then if you get stuck, give me a shot and I'll see if I can answer your questions.
Great. Thank you very much, everybody.
Yes, as Mark says,
thank you to Tracy from Behind the Scenes who was managed today.
I hope that you all enjoyed the session today.
If you missed any part of this,
it will be loaded up to WordPress TV afterwards.
And then I am also recording a tutorial version of this that will go on to learn WordPress
sometime in the future so that if you need a shortened more sort of abbreviated version of
all this information it will be there as well. Thank you all for joining me. I hope you have a
wonderful rest of your Thursday and your weekend weekend and I will see you all next week for some
to be determined workshop. Thank you very much. Bye-bye.
You
(silence)
Thank you.