How the WordPress Block Editor Changes the Conversation for Content Editors and Developers

1. https://javascriptforwp.com/product/gutenberg-block-development-course/

Editor's Notes

hi
this presentation is not overly technical but will get into some technical things
resources and approaches for developers starting out in gutenberg development
things for content editors and site administrators to know about working with gutenberg and also having those conversations with developers
this presentation was built almost entirely in gutenberg to show the different types of things that can be done
hi
this presentation is not overly technical but will get into some technical things
resources and approaches for developers starting out in gutenberg development
things for content editors and site administrators to know about working with gutenberg and also having those conversations with developers
this presentation was built almost entirely in gutenberg to show the different types of things that can be done
Block editor added in WordPress 5.0
2 years of development
React-based editor
Entirely built on top of the WP REST API
Now referred to as “block editor”
Almost 10,000 commits
Nearly 400 contributors
Over 900 releases
* significant development and person-hours involved in this product
What problem is the block editor trying to solve?
* WP admin hasn’t been updated in years, losing ground to more intuitive editorial interfaces like Squarespace and Medium
WP has outgrown TinyMCE
Full control over page layout in WP has been difficult, requiring editors to learn and remember shortcodes, use third party tools like Shortcake, or page builder tools like Beaver Builder and Visual Composer to solve those problems
pull quotes
columns
tables — previously would have required knowledge of html or copy/pasting from a spreadsheet
Like the Customizer, the block editor establishes a standardized toolset for adding editorial components
First major internal component of WP built almost entirely in javascript.
* Uses React
* some licensing concerns about that
* React is maintained by Facebook, some ideological and maintenance concerns around that
* React was chosen over Vue, a smaller, more independent library, some philosophical concerns around that
* Pretty steep learning curve for both javascript, generally, and react specifically
* Forward-thinking architecture -- uses ESNext / JSX
* React can be ripped out if needed, and WP-specific wrappers are used for most things
Modern, block-based editor for more control over dynamic layouts and content types within posts
First time significant attention and development has been spent on a UX component of WordPress
Accessibility
* While individual parts of the block editor might be accessible, Gutenberg was not developed from an accessibility-first standpoint, which led to many accessibility fixes being handled as an afterthought
* Many tasks are extremely difficult and painful to do with a screen reader
* Keyboard shortcuts exist but it’s not always clear how to get to them
* Individual blocks will only be as accessible as the developers make them
Technical implementation differences

json array of attributes
* stored in the database
all markup is saved in the editor
wrapped in html comments
* those html comments are not rendered in the front-end
another example, full width cover image
wrapped in html comments defining the type of block and a json array of attributes
attributes include the image url, alignment, attachment id
those are then used in the rendered markup
alignment informs the class used, url and attachment id determine the background image url
all the actual markup is standard html
divs, p tags, things a browser would recognize
even if your theme doesn’t support the classes, it will at least display something that looks something like what is supported
and if your theme doesn’t support the classes, you’ll see what that looks like in the editor, so it’s not a surprise when you hit publish
There’s a classic editor block if you don’t know what to use or don’t want or need the Gutenberg flow
this works the same way you’d expect, hitting enter starts a new paragraph within the classic editor block rather than opening a new gutenberg block
You need to search for the block, but if you’re using it frequently, it’ll float to the top of your Most Used blocks
The actual markup is exactly what you’d expect — no additional gutenberg block markup at all.
If you absolutely don’t want to work with gutenberg or your site’s not ready to make the switch, the classic editor plugin is available
a bit of an end-of-life for the plugin as it’s only expected to be supported until 2022
it may be maintained and supported longer, but by that time, plugins and themes may move beyond supporting the classic editor and you’ll start to see compatibility issues there
ClassicPress is a hard fork of WordPress prior to 5.0 that only uses the classic, TinyMCE editor
What do I need to know as a developer to start working with the block editor?
I’ll tell you a couple things you don’t need to know.
You don’t need to know React — but it helps
You don’t need to know ES6 or ESNext — but it helps a lot
Gutenberg was written in React and ESNext so it helps in understanding the core modules if you are at least partially familiar with these languages.
But blocks can be written in vanilla javascript and ES5.
Making use of ESNext syntax and JSX is a lot more intuitive and easier to learn that I had anticipated
All the React components used have WordPress-specific wrappers so you’re not interacting with React itself very frequently (outside of core development)
Zak Gordon’s Gutenberg Block Development course is a huge asset
this course will go over some of the JSX and ESNext syntax used in gutenberg block development
hm-gutenberg-tools
Tools and components that can help in Gutenberg development
Gutenberg Starter Kit
Gutenberg plugin boilerplate with example code
Hot Module Replacement for Gutenberg
Hot Module Replacement allows components to update live on the page as you make changes to the code and the code is compiled
This is a huge asset to Gutenberg development
If code is out of sync, Gutenberg will often break during development — this solves that problem so you don’t constantly have to reload
It’s a long read but it’s pretty comprehensive and explains how we’ve used it on multiple projects
There are some general philosophies for developing blocks
You are developing for the admin rather than the front-end
For those of us who consider themselves “back end developers”, this is a pretty big context-shift
Things that were previously handled with shortcodes should probably be Gutenberg blocks
But it’s not a 1:1 conversion -- user interaction and experience needs to be more fully considered
Metaboxes should be re-thought
Many places a custom metabox was used might be better served inline with an interactive Gutenberg block
Stronger emphasis on “what you see is what you get”
All the styles used in the admin to render your block should be the same as those used on the front-end
What do I need to know as an editor using Gutenberg?
You have blocks!
Consider the experience of OEmbed in the WordPress editor as a comparison
For bespoke projects, you will need to be clearer about your requirements
The specific interactions can be highly individualized, which means far more clarity will be needed when considering implementation
Gutenberg blocks take longer to develop
Whereas previously, a custom metabox or shortcode could be developed in less than a day, expect several days worth of development for a similar Gutenberg block...at least as your development team is getting familiar with the tools and the workflow
But it’s worth it
You can do things in a gutenberg block that simply weren’t possible before
Some ideas off the top of my head of things that could be built in Gutenberg
Translations
A translatable text block could be created that allows direct translations to be handled inline
Embeddable contact and newsletter signup forms
Customizable fields can be added or not
Featured content
A pull-out highlighting content somewhere else on the site
Logic can be contextual or manually curated
Ads and third party embeds
Ad placement and embeds can happen inline within the editor, so content editors always know where these things will display on the page
Placement can be manual or through automated logic
A/B testing
A block or series of blocks could be created to test out different content or design strategies
Nested blocks
Blocks inside blocks inside blocks
any questions?
Zak’s G’berg block development course
HM repos
HM article on HMR
HM has written a white paper about Gutenberg and what it can do
My info

How the WordPress Block Editor Changes the Conversation for Content Editors and Developers

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

Ad

You are reading a preview.

How the WordPress Block Editor Changes the Conversation for Content Editors and Developers

More Related Content

Slideshows for you (16)

More from Chris Reynolds (10)

Featured (20)

How the WordPress Block Editor Changes the Conversation for Content Editors and Developers

Editor's Notes