Meta tags:
description=I’m going to go write a series of articles in which I’ll share my experience as something like “a backend engineer is learning to build Block Editor blocks.”;

Headings (most frequently used words):

block, editor, the, backend, to, build, blocks, required, plugin, dependencies, frontend, and, content, post, engineer, learns, part, learning, todo, reference, assumptions, tools, set, up, your, structure, wordpress, creating, header, metadata, understanding, src, directory, starting, our, displaying, previous, next,

Text of the page (most frequently used words):
the (204), and (81), block (81), this (66), that (50), with (40), for (38), you (35), wordpress (33), from (33), editor (32), #plugin (28), are (27), blocks (23), json (23), but (20), build (19), going (19), like (18), how (17), all (16), what (16), can (16), file (16), use (15), there (15), name (15), start (14), php (13), #frontend (13), something (13), article (13), our (13), work (13), backend (13), scripts (13), directory (12), development (11), learning (11), articles (11), package (11), things (11), content (11), will (11), not (11), about (10), they (10), working (10), tom (9), more (9), function (9), some (9), though (9), which (9), where (9), was (9), sure (9), version (9), when (9), have (8), get (8), writing (8), using (8), look (8), code (8), then (8), demo (8), series (8), author (8), https (8), description (8), later (8), packages (8), mcfarlin (7), include (7), these (7), new (7), javascript (7), may (7), need (7), npm (7), metadata (7), because (7), com (7), make (7), license (7), dependencies (7), recommend (6), registerblocktype (6), used (6), reference (6), want (6), change (6), see (6), save (6), index (6), who (6), within (6), don (6), first (6), src (6), tommcfarlin (6), looks (6), uri (6), gpl (6), install (6), know (6), 2022 (5), just (5), started (5), next (5), jsx (5), should (5), functionality (5), add (5), isn (5), read (5), your (5), following (5), different (5), other (5), edit (5), little (5), point (5), before (5), here (5), engineer (5), structure (5), help (5), building (5), its (5), aren (5), various (5), components (5), write (4), out (4), also (4), hosting (4), post (4), tutorials (4), into (4), destructuring (4), called (4), comes (4), schema (4), create (4), built (4), both (4), run (4), anything (4), object (4), import (4), return (4), context (4), enough (4), expect (4), doesn (4), attribute (4), any (4), starting (4), place (4), namespace (4), org (4), future (4), title (4), includes (4), time (4), standard (4), required (4), share (4), said (4), lint (4), versions (4), software (4), lot (3), getting (3), looking (3), section (3), wpkube (3), take (3), kinsta (3), search (3), syntax (3), makes (3), properties (3), plugins (3), css (3), everything (3), show (3), basic (3), thing (3), doing (3), has (3), after (3), once (3), notice (3), talking (3), give (3), many (3), material (3), const (3), think (3), such (3), goes (3), actually (3), text (3), reading (3), easy (3), data (3), set (3), core (3), note (3), developer (3), above (3), tmbd (3), running (3), update (3), header (3), good (3), two (3), rendered (3), speaking (3), them (3), tools (3), try (3), latter (3), does (3), format (3), each (3), notes (3), tooling (3), nvm (3), node (3), projects (3), long (3), learn (3), whatever (3), years (3), wasn (3), theme (2), checking (2), free (2), gutenberg (2), previous (2), every (2), type (2), register (2), react (2), describe (2), full (2), creating (2), attributes (2), scaffolding (2), project (2), specifically (2), style (2), only (2), terminal (2), browser (2), very (2), api (2), information (2), linked (2), copy (2), really (2), simple (2), added (2), render (2), named (2), easily (2), mental (2), map (2), means (2), maybe (2), appear (2), under (2), variable (2), property (2), created (2), certain (2), especially (2), end (2), storing (2), further (2), key (2), works (2), already (2), described (2), current (2), best (2), understanding (2), diverge (2), bit (2), august (2), add_action (2), www (2), gnu (2), licenses (2), html (2), defined (2), wpinc (2), die (2), files (2), primarily (2), node_modules (2), tells (2), script (2), editorscript (2), associated (2), continues (2), icon (2), category (2), refers (2), clear (2), matter (2), collisions (2), references (2), most (2), apiversion (2), however (2), forward (2), define (2), aspects (2), published (2), database (2), now (2), developers (2), application (2), yet (2), mean (2), patterns (2), always (2), details (2), nothing (2), able (2), github (2), find (2), explain (2), else (2), worth (2), devdependencies (2), zip (2), than (2), exactly (2), necessary (2), documentation (2), familiar (2), whenever (2), needed (2), installed (2), installing (2), npx (2), homebrew (2), been (2), along (2), necessarily (2), consistent (2), least (2), similar (2), captures (2), organize (2), come (2), few (2), still (2), fan (2), someone (2), mind (2), release (2), user (2), part (2), contact (2), partners (2), resources (2), categories (2), toggle (2), web (2), anders, noren, glossary, training, videos, wpbeginner, guides, unbiased, reviews, exclusive, deals, offers, premium, managed, everyone, small, large, powered, google, platform, performance, level, plans, 24x7, support, their, team, engineers, migration, today, dracula, preformatted, times, starts, registering, definition, expression, possible, unpack, values, arrays, objects, distinct, variables, assignment, handbook, extension, remind, template, language, power, introducing, official, documents, during, officially, supported, tool, generates, customize, styling, adding, styles, todo, foundation, refresh, click, option, done, wait, top, line, call, pass, containing, functions, final, edi, elaborate, rest, responsible, saved, table, those, view, site, post_content, last, clearly, could, displaying, activate, interesting, happens, depending, label, configuration, deconstruct, essentially, saying, taking, apart, kind, weird, oriented, background, hang, pretty, convenient, earlier, important, understand, finally, begins, pay, attention, referenced, purpose, reason, additional, practices, source, reside, conversation, registers, since, init, register_block_type, dirname, __dir__, included, plugins_loaded, include_once, addition, directories, well, result, takeaway, screenshot, lock, relies, visual, indicator, retrieved, again, dashicons, throughout, group, available, same, too, keep, sync, prefix, practice, informs, anyone, recent, provides, against, prevent, schemas, trunk, flag, initial, entire, link, bare, necessities, moving, one, pieces, knowing, depth, short, allows, refer, strictly, presented, previewing, viewing, libraries, gives, ability, post_meta, website, tend, being, layer, down, system, somewhere, initially, common, even, anyway, fair, bad, talk, together, contained, emerging, stick, applicable, refactor, towards, definitive, ready, setting, 1604, audited, 1605, 201, funding, fund, found, vulnerabilities, assuming, wrong, gitignore, please, cool, stuff, resides, interfaces, control, sense, worries, panelrow, panel, richtext, collection, reusable, tailored, words, proper, licensing, testing, preparing, archiving, linting, put, aside, exploring, custom, main, list, contents, dependency, area, namely, mine, easiest, require, example, let, outline, showcase, document, gplv2, changes, made, evangelized, keepachangelog, changelog, eventually, installation, shouldn, readme, much, utility, except, instead, composer, scratch, off, ground, layout, foundational, interested, bottom, listed, v18, related, former, execute, command, without, having, otherwise, never, parts, vanilla, utilities, usual, managers, hard, assume, position, assumptions, way, journey, experience, rocky, beginning, functional, ending, places, seem, popular, credit, deserve, ryan, welcher, reiterate, shared, thought, might, holding, myself, task, mentioned, better, helps, figure, maps, fails, plenty, people, online, right, direction, basics, ways, easier, standpoint, satisfied, fact, perhaps, won, claim, amazing, regardless, fast, far, comfortable, seems, settled, hit, posts, reads, particularly, experimental, plus, coming, generally, completely, paradigm, tough, industry, happening, incredible, pace, inconsistency, problem, fond, changing, gets, frustrating, while, demotivate, step, away, lukewarm, simply, around, curve, day, developing, muscle, memory, ago, excited, learns, field, mobile, menu, skip, wayback, machine, http, archive, 20221204164754, timestamps, capture, fail, success, 2023, 2021, jan, dec, nov, aug, mar, 2026,

Text of the page (random words):
f that said though i thought it might be worth holding myself to the task i mentioned in the previous article on writing better the block editor tutorials before going any further i want to reiterate something that i ve already shared ryan welcher and learn wordpress are two places that seem to be the most popular for learning block development and i want to make sure they get the credit they deserve starting with this post i m going to go write a series of articles in which i ll share my experience as something like a backend engineer is learning to build block editor blocks i ll go from the very rocky beginning to the full functional ending maybe it ll help some of you along the way and if not at least it captures my journey learning to build block editor blocks assumptions when writing articles like this it can be hard to know where to start so i m going to assume if you re reading this you re in a similar position than i am you ve been working in software development for a long time you re familiar with the usual package managers for both frontend and backend development you know how to install various utilities with homebrew you ve been following along with the block editor for long enough to know it use react and can work with both jsx and vanilla javascript and that it doesn t necessarily matter which you use so long as you re consistent at least that s my take on it otherwise i ll never get to the core parts of actually building something required tools so with that said these are the frontend tools that i use to get up and running with block development note that all of these can be installed with homebrew node this will also install npm and npx the former is used to install dependencies the latter is used to execute a command without actually having to first install it nvm i recommend installing this because if you re working with various projects that have different frontend tooling then you re going to want to easily change versions of node and its related packages this makes it easy to do at the time of writing this article the versions of each of the above software that i m using are node is at v18 4 0 npm is at 8 12 1 npx is at 8 12 1 nvm is at 0 39 1 if you have latter versions of npm installed i recommend installing nvm and then running the versions listed above as i know they work with the code in the context of this article though i m going to write this article with all of the code starting from scratch there is tooling that we can use to help get us off the ground but before using that i want to layout the foundational aspects of block development so there s a clear understanding of everything that s needed if you re interested in said tooling you ll find it in the references section at the bottom of this article ️ set up your plugin structure whenever i m starting to work on a block the structure for the plugin isn t much different from how it looks when i m working on a backend utility except for i m not using composer json instead i use package json readme md will eventually include all of the details about the plugin from its description its installation and any other notes if you re familiar with anything i ve published on github this shouldn t be new changelog md includes all of the changes made in the plugin in the format evangelized by keepachangelog com license is a text copy of the gplv2 though i document the plugin to work with gpl 2 0 or later plugin php includes the necessary wordpress plugin documentation which i ll showcase later in this article package json includes all of the dependencies and packages i use when working on a block i ll also share this later in the article and outline what each package does this means my directory structure looks like the following it s exactly as described but let me share the two core components that are necessary for it to work within wordpress ️ required wordpress dependencies plugin header i m going to start with this because it s the easiest and it s something that all plugins require you can see an example of what i m talking about here for the block plugin i m working on mine looks like this php plugin name block demo plugin plugin uri https tommcfarlin com description a demo plugin built by a backend engineer learning to build block editor blocks version 1 0 0 author tom mcfarlin author uri https tommcfarlin com license gpl 2 0 or later license uri https www gnu org licenses gpl 2 0 html namespace tmbd defined wpinc die at this point this should do nothing more than show you exactly what you d expect to see in the plugins area of wordpress namely the title author and the description block dependencies the next thing we need to do is to define the dependencies used in package json these are the things that are going to help us build blocks use various components in the block editor and so on first i ll list the contents of package json here and then i ll explain what each dependency does name tm custom block version 1 0 0 description a demo plugin built by a backend engineer learning to build block editor blocks author tom mcfarlin license gpl 2 0 or later main build index js scripts build wp scripts build format wp scripts format lint css wp scripts lint style lint js wp scripts lint js packages update wp scripts packages update plugin zip wp scripts plugin zip start wp scripts start devdependencies wordpress scripts 23 7 1 dependencies wordpress components 19 17 0 aside from the standard name version description author and license properties everything else under the scripts and devdependencies and dependencies are worth exploring i ll start with the latter then explain what the scripts section does wordpress scripts is a collection of reusable scripts tailored for wordpress development in other words it makes it easy to make sure we re following proper licensing testing preparing the plugin for archiving linting both css and js and more we ll put this to use in future articles wordpress components is where a lot of the cool stuff resides this is where we ll find many of the various ui components that we ll use to build the interfaces within our blocks this may include things like a richtext control or a panel or a panelrow and if these don t make sense no worries i ll get to them in a future post with that in place you should be able to run npm install from your terminal and it ll create the node_modules directory if you re storing this code on github please make sure to add that directory to gitignore assuming nothing goes wrong you should see something like the following added 1604 packages and audited 1605 packages in 2m 201 packages are looking for funding run npm fund for details found 0 vulnerabilities at this point we re ready to start setting up a block creating a block because there isn t yet a definitive standard on how to do it various tutorials are going to diverge here but that doesn t mean there aren t patterns that are emerging so i m going to try to stick to said patterns when applicable and if i don t i ll always try to refactor towards them as this series continues anyway it s fair to note that some tutorials will recommend scaffolding tools which aren t all bad some are going to talk about block json some are going to start talking about block attributes which aren t all together different from content contained within block json so we ll start somewhere and build up from there even if some of the things we do initially aren t as common the frontend and the backend when it comes to working with blocks as they appear in the block editor and on the frontend of the website i m not sure how to best describe them as backend developers we tend to think of the backend of the application as being anything from the application layer down into the database or the file system but when it comes to working with blocks in the block editor it s a little different later in this series of articles i ll share how the block editor and its associated libraries gives us the ability to read data from the database such as post_meta but for now i m going to start with something more basic and in this context when i refer to the backend and the frontend i m strictly speaking of how data is rendered in the editor and how it s presented to what s rendered in the browser when previewing an article or viewing a published article block metadata one of the key pieces to building a block is knowing how to use block json i ll write about this in more depth as the series goes on but the short of it that block json allows us to define certain aspects of our block that will be read by wordpress and rendered in the editor there s an entire schema for how to set it up which i ll link in the reference material but i m just going to to include the bare necessities before moving forward with the first block the initial block json that s required to start looks something like this schema https schemas wp org trunk block json apiversion 2 name tm tm block demo version 1 0 0 title block demo category text icon flag editorscript file index js the only two things that are required are title and content however i include a little more information to give context to the block and to help prevent any collisions with other blocks the schema attribute provides a reference to what i m using as the standard against which i m writing my block json file the apiversion informs me and anyone who references the code which version of the block api i m using at the time of this writing 2 is the most recent the name attribute is includes a prefix of tm this is a good practice just as we use namespace in php so that we don t have collisions with other blocks the version refers to the current version of the block i keep this in sync with the version in the plugin header and in the package json file so it s clear no matter where you look the title attribute refers to the name of the plugin the description property is the same description i give in the plugin header and the package json file too category is something that will change throughout this series of articles but it tells wordpress where to place our block in the group of blocks that are available in the block editor icon is a simple visual indicator associated with our block these are retrieved from dashicons again i ll change this as the series continues editorscript tells wordpress where the primarily block script relies this script will include all functionality for this article and future articles at this point we need to update our directory structure our plugin php file and add a block php file to the plugin first our directory structure will look like this notice the addition of the build directories and the node_modules directory as well as the package lock json files these are a result of running npm install but the primarily takeaway from this screenshot is to notice the src directory before looking in there make sure your plugin php file looks like this php plugin name block demo plugin plugin uri https tommcfarlin com description a demo plugin built by a backend engineer learning to build block editor blocks version 1 0 0 author tom mcfarlin author uri https tommcfarlin com license gpl 2 0 or later license uri https www gnu org licenses gpl 2 0 html namespace tmbd defined wpinc die add_action plugins_loaded function include_once src block php then in your src directory make sure block json is included then add you a file called block php that looks like this php registers the code with the block editor author tom mcfarlin tom tommcfarlin com since 29 august 2022 namespace tmbd add_action init function register_block_type dirname __dir__ build here we need to diverge our conversation a little bit understanding the src directory i ve already described the purpose of block json above but the reason we need to place an additional php file within the directory is because current best practices for block editor development expect block source code to reside in the src directory finally within the src directory we need to include an index js file this is where the core block functionality begins note that if you re a backend developer it s key to pay attention to how this file works as we re going to be using jsx referenced at the end of the article to work with our code starting our block to start we ll set up index js to look like this import metadata from block json const name metadata registerblocktype name before going any further there are some javascript syntax that are important to understand import is reading data from the block json file we created earlier and it s storing it in a variable called metadata const name is what s called javascript destructuring such that it s taking apart the object that was created and reading a certain attribute for it destructuring is kind of weird at first especially from an object oriented background but once you get the hang out it it s pretty easy to work with and can be really convenient i ve linked a reference to it at the end of the article essentially what we re saying is read the block configuration file into a variable named metadata and then deconstruct the object and read the name property after that we ll register the block type with wordpress using that name at this point we can activate the plugin but something interesting happens or maybe not depending on what you expect you ll see the block appear under the text label but it doesn t actually do anything this means we have a little more work to do displaying editor content and frontend content the last thing we need to do is to add an edit function and a save function to our index js file though i don t think they are as clearly named as they could be they are name easily enough such that we can create a mental map of what goes where the edit function is used to render the content of our block within the context of the block editor the save function is responsible for how the content added in the editor will be saved to the post_content table and render to those who view the site for this article we re going to start with something really simple and will elaborate on it for more in the rest of the series the edi t function can look like this edit return this is content from the editor and the save function can look like this save return this is content from the frontend so the final copy of index js will look like this import registerblocktype from wordpress blocks import metadata from block json const name metadata registerblocktype name edit return this is content from the editor save return this is content from the frontend wait though notice anything different at the very top of the file there s a new line from the wordpress blocks package specifically i m talking about registerblocktype this is an api call to wordpress to give it some information from what we take from block json and what we pass into the object containing functions for edit and save like many other things this is linked in the ref...