Update blocks to build using wp-scripts and register with block.json - starting with oik-bw/wp

[bobbingwide]

I want to be able to style the output of the "oik-bbw/wp" block using the global styles solution.

The blocks in oik-bob-bing-wide are currently:

• written using the old style method const { __ } = wp.i18n; rather than the package method import { __ } from '@wordpress/i18n';
• built using a hand cranked webpack build
• registered manually in both JavaScript and server

I believe that in order to be able to allow the blocks to support typography, colours and so on, that I need to change them:

• to be written using the new method
• to be built using wp-scripts
• to be registered from block.json - similar to sb-post-edit-block
• to use API version 2

Requirements

• to support end user customization of block's font size, colour etc

Proposed solution

I know that the sb-post-edit-block allows this customisation, so I'll aim to build the blocks using the same method.

• to use API version 2
• to register blocks using block.json...
• in the server using register_block_type_from_metadata() or whatever's the flavour of the month.
• in the JavaScript using metadata loaded from block.json.
• to render SSR blocks using the new techniques involving get_block_wrapper_attributes()

If the solution doesn't work then I'll be mystified, but at least I'll be better prepared for the future.

[bobbingwide]

Before starting this work I decided to commit the changes I'd made.
I rebuilt the code for a production build and was surprised to find that the WordPress block now supported setting the font size.
It worked in the editor but the SSR logic couldn't handle the fontSize attribute.

<!-- wp:oik-bbw/wp {"fontSize":"extra-small"} /-->

Before I make the other changes, I'm going update the server logic to support the additional attributes that could be expected
were an attempt be made to override the block's original logic.
This will get me one step further with the Written theme, where the font size needs to be smaller when the block is used in the sidebar.

[bobbingwide]

I updated the server logic. It took a bit of time finding the right values for block.json
and even though I added the supports section I still needed to add each of the attributes being passed
by the different controls.
If an attribute wasn't defined the block would fail with Error loading block: Invalid parameter(s): attributes
eg

{"code":"rest_invalid_param","message":"Invalid parameter(s): attributes","data":{"status":400,"params":{"attributes":"fontSize is not a valid property of Object."},"details":{"attributes":{"code":"rest_additional_properties_forbidden","message":"fontSize is not a valid property of Object.","data":null}}}}

So far I've had to add className, backgroundColor, style and now fontSize.
Is it never ending?

[bobbingwide]

The block's now behaving like the sb-post-edit-block behaved when it didn't have any toolbar icons.

You can't select it easily.

[bobbingwide]

And style's an object, not a string.

{"code":"rest_invalid_param","message":"Invalid parameter(s): attributes","data":{"status":400,"params":{"attributes":"[style] is not of type string."},"details":{"attributes":{"code":"rest_invalid_type","message":"[style] is not of type string.","data":{"param":"[style]"}}}}}

[bobbingwide]

Another problem that I had was with the CSS associated with the fontSize attribute.

The values were being set at the block level.

<div style="background-color: #dbddc0; font-size: 13px;" class="has-background is-style-fancy wp-block-oik-bbw-wp">
<p>WordPress version: 5.8-beta4</p>
<p>Gutenberg version: 11.1.0.20210702</p>
</div>

The fontSize defined against the <div> was being overridden by the default font size for the paragraph,
which wasn't what I wanted.

My initial solution was to change the tags used to <span>s with a separating <br />.

<div style="background-color: #dbddc0; font-size: 13px;" class="has-background is-style-fancy wp-block-oik-bbw-wp">
<span class="label">WordPress version: </span>
<span class="value">5.8-beta4</span>
<br>
<span class="label">Gutenberg version: </span>
<span class="value">11.1.0.20210702</span>
</div>

[bobbingwide]

I've implemented block.json for oik-bbw/wp in the blocks/oik-wp folder, alongside the source files.

This may cause problems in the future:

1. Will the files be included in the plugin's .zip file?
2. Will the files be accessible to i18n routines?

Notes:

• Gutenberg has a process that copies files from source to the build folder.
• This seems a bit unnecessary.
• Perhaps it would be better to have a new folder such as json.
• If the files do get moved the block.json file(s) will probably need updating to change the relative directory of the build files.
• It was hard enough determining what I needed to put in block.json in the first place. See Update blocks to build using wp-scripts and register with block.json - starting with oik-bw/wp  #42 (comment)

[bobbingwide]

The oik-bob-bing-wide plugin was originally built using webpack.

When used in WordPress 5.8 the Widget block editor produces a "doing it wrong" message due to the enqueueing of wp-editor.
It seems the best solution is to rework the code to build it using wp-scripts which will enable use of

import ServerSideRender from '@wordpress/server-side-render';

See bobbingwide/bobbingwide#30 (comment)

Requirements

• Ability to use the Widget block editor without getting messages regarding wp-editor.
• Which means changing the build to allow the import above.
• Build using wp-scripts
• Register the blocks using block.json
• Ensure the blocks can be selected
• Add some color and typography settings where applicable
• Add text align capability where applicable

Proposed solution

• Copy and cobble the solution developed for UK-tides v3.0.0, as this is now ahead of sb-starting-block
• Remove unnecessary files: webpack.config.js and .babelrc
• Change package.json
• Change block.json for each block
• Change each block's index.js to register the block
• Change each block's Server Side Registration to register the block from block.json
• Change each block to use get_block_wrapper_attributes(), where needed to apply CSS classnames, text align etc..
• Update node_modules and rebuild

Process for updating node_modules

1. Remove the existing node_modules folder
2. npm install
3. npm install @wordpress/scripts --save-dev

See https://developer.wordpress.org/block-editor/reference-guides/packages/packages-scripts/

[bobbingwide]

While refactoring the blocks I came across the following message for a number of the blocks.

The block "oik-bbw/search" must have a title.

This was when I'd changed the JavaScript to register the block using just the block name and not the metadata from block.json but when the block wasn't being registered on the server.

The solution is to register the block from block.json on the server.

[bobbingwide]

While updating the oik-bbw/dashicon block I found a method that enabled me to use the Typography controls to set the font size. I also found it fairly easy to set the foreground colour, but not the background colour.
The background colour applies to the whole <div> not just the <span> for the dashicon.

I also discovered, by reading the documentation, that in the save method you need to call useBlockProps.save().

save: props => {
   	const blockProps = useBlockProps.save();
            return(
		<div {...blockProps} >
                 <Dashicon icon={props.attributes.dashicon} />
		</div>

            );

I may need to use this technique for some other blocks.
See https://developer.wordpress.org/block-editor/reference-guides/block-api/block-edit-save/

[bobbingwide]

2. Will the files be accessible to i18n routines?

As determined when updating oik for Internationalization and Localization, the block.json files in the src folder can be processed by makepot with the following changes to the build command in package.json.

From:

"makepot": "wp i18n make-pot . languages/oik-bob-bing-wide.pot --exclude=node_modules,vendor,src",

To:

"makepot": "wp i18n make-pot . languages/oik-bob-bing-wide.pot --ignore-domain --domain=oik-bob-bing-wide --exclude=node_modules,vendor,src/*.js,tests",

• --ignore-domain is required to load strings from PHP shared library files
• --domain=oik-bob-bing-wide defines the domain to use
• src/*.js,tests - only exclude the .js files from src. Also exclude the tests folder

Other changes are needed in the code to:

• load the plugin textdomain before the blocks are registered
• remove the textdomain attribute from block.json files
• add a filter for block_type_metadata to set the textdomain attribute at runtime.
• call wp_set_script_translations() to localize the blocks in the editor

[bobbingwide]

After updating the makepot command it failed with an out of memory fatal error.

> [email protected] makepot C:\apache\htdocs\wordpress\wp-content\plugins\oik-bob-bing-wide
> wp i18n make-pot . languages/oik-bob-bing-wide.pot --ignore-domain --domain=oik-bob-bing-wide --exclude=node_modules,vendor,src/*.js,tests

Plugin file detected.

Fatal error: Allowed memory size of 268435456 bytes exhausted (tried to allocate 20480 bytes) in phar://C:/d_drive/dos/wp-cli.phar/vendor/mck89/peast/lib/Peast/Syntax/CommentsRegistry.php on line 172

Increasing the memory did not resolve the problem. It took longer to fail, in a different line of code

Fatal error: Allowed memory size of 536870912 bytes exhausted (tried to allocate 4096 bytes) in phar://C:/d_drive/dos/wp-cli.phar/vendor/mck89/peast/lib/Peast/Syntax/ParserAbstract.php on line 235

Explanation

The problem occurred when parsing the files in shortcodes/jquery: vis.js and vis-public.js
Excluding these enabled the process to run to completion, with 256M memory

> [email protected] makepot C:\apache\htdocs\wordpress\wp-content\plugins\oik-bob-bing-wide
> wp i18n make-pot . languages/oik-bob-bing-wide.pot --domain=oik-bob-bing-wide --exclude=node_modules,vendor,src/*.js,tests,shortcodes/jquery

Plugin file detected.
Success: POT file successfully generated!

[bobbingwide]

wp-scripts is now v22.1.0. While refactoring the Dashicon block in issue #46, to be delivered in oik-bob-bing-wide v2.2.1, I've finally discovered how to build each block as a separately deliverable unit.

I want to revisit the method I'd used to deliver multiple internationalized blocks in build/index.js and deliver each block in its own package. The terminology used for this in wp-scripts is entry point.

The official documentation at https://developer.wordpress.org/block-editor/reference-guides/packages/packages-scripts/#build states

The fallback entry point is src/index.js (other supported extensions: .jsx, .ts, and .tsx) in case there is no block.json file found. The output generated will be written to build/index.js.

The documentation shows a custom build where the entry points and custom --output-path are specified on the wp-scripts command line. I haven't worked out how to use this. Instead, looking at the code generated by Ryan Welcher's https://github.com/ryanwelcher/create-block-multple-blocks-template I learnt what I needed to write in webpack.config.js.

This has been a long journey!

Requirements

• Deliver blocks separately
• Continue to support internationalization and localization

Proposed solution

• Use a similar technique to Update to the latest @wordpress/scripts package and rework as required sb-starting-block#3, taking into account the fact that I've already updated wp-scripts.

Each block's block.json file will need updating to define editorScript, editorStyle and style, where required, replacing index with the block name, excluding the prefix. eg for oik-bbw/csv it's csv.

• Add the "$schema" attribute at the same time

[bobbingwide]

Delivered in v2.2.1. Closing therefore.