Presentation delivered 11.10.19 @ WidgiLabs Training Sessions (https://widgilabs.com)

1. The “Gutenberg”
Block Editor
WL Training Sessions

2. https://wordpress.org/
gutenberg/

3. The “Gutenberg” Block
Editor
• Goal: Make writing rich posts effortless.
• How? Treating a post as being composed of distinct pieces
of content called “blocks”.
• Approach:
• These pieces should be easy to insert and manipulate,
providing rich and contextual interfaces to interact with as
you craft a post.
• Easy to search and understand, and easy to dynamically
shift around the page.

4. The “Gutenberg” Block
Editor : Technical
• Transition from the content blob to each piece of content
being its own “block”
• Instead of the crude mixture of custom HTML,
"shortcodes" and "embeds", every element will be a
block
• Each block has its own properties and attributes
• React.js based

5. Why does this matter?
• The front-end of pretty much every WordPress site up
until this moment is a template displaying content in a
relatively rigid way
• Within the next few months – the block concept will spill
outside the content area to take over the whole view.
• Keeping up-to-date and not be in denial against what the
future holds.
• New business opportunities. New learning opportunities.

6. What we think of as a
“WordPress theme” is
already an outdated concept!

7. 9 priorities outlined by Matt
1. Creating a block for navigation menus.
2. Port all existing widgets to blocks.
3. Upgrade the widgets-editing areas and the Customizer to support blocks.
4. Provide a way for themes to visually register content areas, and expose them in Gutenberg.
5. Merge the site health check plugin into Core, to assist with debugging and encourage
good software hygiene.
6. Provide a way for users to opt-in to automatic plugin and theme updates.
7. Provide a way for users to opt-in to automatic updates of major Core releases.
8. Build a WordPress.org directory for discovering blocks, and a way to seamlessly install
them.
9. Form a Triage team to tackle our 6,500 open issues on Trac.

8. 5 priorities are with Blocks
1.Creating a block for navigation menus. (BLOCK RELATED)
2.Port all existing widgets to blocks. (BLOCK RELATED)
3.Upgrade the widgets-editing areas and the Customizer to support blocks. (BLOCK RELATED)
4.Provide a way for themes to visually register content areas, and expose them in Gutenberg. <—
_______ (BLOCK RELATED)
5.Merge the site health check plugin into Core, to assist with debugging and encourage good software
hygiene.
6.Provide a way for users to opt-in to automatic plugin and theme updates.
7.Provide a way for users to opt-in to automatic updates of major Core releases.
8.Build a WordPress.org directory for discovering blocks, and a way to seamlessly install them. <—_
___ (BLOCK RELATED)
9.Form a Triage team to tackle our 6,500 open issues on Trac.

9. Block Design
• The primary interface for a block is the content area of the
block (“fill in the blanks” approach)
• After the user has added content, selecting the block can
reveal additional controls to adjust or edit that content.
• The Block Toolbar is a secondary place for required options
& controls. The Settings Toolbar is hidden on mobile.
• Setup states, sometimes referred to as “placeholders”, can
be used to walk users through an initial process before
showing the live preview state of the block
https://developer.wordpress.org/block-editor/designers/block-design/

10. Block Development
• Register
• Block edit and save
• How a block is going to be rendered within the editor,
how it will operate and be manipulated, and how it will
be saved.
• wp_enqueue your js file and use
blocks.registerBlockType

11. Block Development
• https://ahmadawais.com/create-guten-block-toolkit/
• hides all configuration away in an npm package
called cgb-scripts

12. Validation
• When the editor loads, all blocks within post content are
validated to determine their accuracy in order to protect
against content loss.
• During editor init, the saved markup for each block is
regenerated using the attributes that were parsed from the
post’s content.
• If the newly-generated markup does not match what was
already stored in post content, the block is marked as
invalid.
•Overwrite, Convert or Edit as HTML

13. Deprecated Blocks
• When updating static blocks markup and attributes, block authors
need to consider existing posts using the old versions of their
block.
• Strategies:
• Do not deprecate the block and create a new one (a different
name)
• Provide a “deprecated” version of the block allowing users
opening these in the block editor to edit them using the updated
block.
• A block can have several deprecated versions.

14. Templates
• A block template is defined as a list of block items.
• Such blocks can have predefined attributes, placeholder
content, and be static or dynamic.
• Block templates allow to specify a default initial state for
an editor session.
https://developer.wordpress.org/block-editor/developers/block-api/block-templates/

15. const { registerBlockType } = wp.blocks;
const { InnerBlocks } = wp.editor;
const BLOCKS_TEMPLATE = [
[ 'core/image', {} ],
[ 'core/paragraph', { placeholder: 'Image Details' } ],
];
registerBlockType( 'myplugin/template', {
title: 'My Template Block',
category: 'widgets',
edit: ( props ) => {
•

16. Block Variations
• Alternative styles and functionality to existing blocks.
• They work by adding a className to the block’s wrapper.
• This className can be used to provide an alternative
styling for the block if the style variation is selected.

17. Dynamic Blocks
• render_callback runs on PHP
• The possibilities are endless.

18. Exercise
• Writing your first block: http://bit.ly/guten-start

19. @WidgiLabs
• We’ve started creating Blocks using ACF Pro.
• Further exploration is needed.
• Learning React.js is mandatory, not optional :-)
• WidgiLabs Block Directory: ?
• wpconferenceblocks.com ?

20. @morgadin
11.10.2019
Thanks!