Rework the WordPress info block then internationalize

[bobbingwide]

The WordPress info block ( oik-bbw/wp ) was originally developed as a couple of shortcodes [wp] and [guts].
[wp] was implemented in oik-bob-bing-wide, [guts] was first implemented in oik-block.

The current version of the block has 4 attributes which are strings:

Attribute	Purpose
v	Display WordPress version when 'v'
p	Display PHP version when 'p'
m	Display Memory limit when 'm'
g	Display Gutenberg version when 'g'

The server side implementation doesn't handle all combinations.
If the g attribute is specified then we run [guts] to display the WordPress and Gutenberg version.
Otherwise we run the original WordPress shortcode.

Requirement

Improve the block and server side rendering to implement a better UI.

Proposed solution

• Change attributes to boolean toggles
• Rework server side code to use the toggles in this order: WordPress version, Gutenberg version, PHP version, Memory limit
• Add an example to display WordPress and Gutenberg versions by default
• Internationalize and localize
• Support font size and colours: text and background/gradient

Consider deprecating the bw_wp() function, implementing the new solution using oik_block_guts() or a new version of it.

[bobbingwide]

When the [guts] shortcode is used in the widget area then there are Warnings produced from

 [0] => (integer) 2
    [1] => (string) "Warning: Trying to access array offset on value of type null"
    [2] => (string) "C:\apache\htdocs\wordpress\wp-includes\class-wp-block-supports.php"
    [3] => (integer) 94

0. bw_lazy_backtrace C:\apache\htdocs\wordpress\wp-content\plugins\oik-bwtrace\libs\bwtrace.php:108 0
1. bw_backtrace C:\apache\htdocs\wordpress\wp-content\plugins\oik-bwtrace\includes\bwtrace-actions.php:286 0
2. bw_trace_error_handler(2,Trying to access array offset on value of type null,C:\apache\htdocs\wordpress\wp-includes\class-wp-block-supports.php,94) C:\apache\htdocs\wordpress\wp-includes\class-wp-block-supports.php:94 4
3. apply_block_supports C:\apache\htdocs\wordpress\wp-includes\class-wp-block-supports.php:171 0
4. get_block_wrapper_attributes(array) C:\apache\htdocs\wordpress\wp-content\plugins\oik-bob-bing-wide\shortcodes\oik-guts.php:27 1
5. oik_block_guts(array,,guts) C:\apache\htdocs\wordpress\wp-content\plugins\oik\libs\oik-shortcodes.php:229 3
6. bw_shortcode_event(array,,guts) C:\apache\htdocs\wordpress\wp-includes\shortcodes.php:356 3

It would appear that get_block_wrapper_attributes() assumes that it's being called for a block.
and that the block's information would be stored in self::$block_to_render.

WordPress 5.8's code never sets this variable.

Workaround

Replace the [guts] shortcode with the block.

Possible solution

Wrap the output from the shortcode function when it's being invoked from a block and call get_block_wrapper_attributes() in this wrapper.

[bobbingwide]

Note: The current solution doesn't display any output when none of the toggles are on. Ditto for the [guts] shortcode.

[bobbingwide]

The current solution does not support align. It would appear that we need to add the align attribute and adjust the classes to include a class prefixed by has-text-align.

[bobbingwide]

I ran npm run packages-update today then ran npm run build
This was the output...

> oik-bob-bing-wide@2.1.0 build C:\apache\htdocs\wordpress\wp-content\plugins\oik-bob-bing-wide
> wp-scripts build

Skipping "../../build/index.js" listed in "C:/apache/htdocs/wordpress/wp-content/plugins/oik-bob-bing-wide/src/oik-csv/block.json". File is located outside of the "src" directory.
assets by chunk 13.7 KiB (name: index)
  asset index.js 12.7 KiB [emitted] [minimized] (name: index)
  asset index.css 765 bytes [emitted] (name: index)
  asset index.asset.php 202 bytes [emitted] (name: index)
asset oik-wp/block.json 1.15 KiB [emitted] [from: src/oik-wp/block.json] [copied]
asset oik-csv/block.json 1.06 KiB [emitted] [from: src/oik-csv/block.json] [copied]
asset github/block.json 1010 bytes [emitted] [from: src/github/block.json] [copied]
asset oik-dashicon/block.json 803 bytes [emitted] [from: src/oik-dashicon/block.json] [copied]
asset oik-search/block.json 752 bytes [emitted] [from: src/oik-search/block.json] [copied]
asset ./style-index.css 347 bytes [emitted] (name: ./style-index) (id hint: style)
Entrypoint index 14 KiB = ./style-index.css 347 bytes index.css 765 bytes index.js 12.7 KiB index.asset.php 202 bytes
orphan modules 30.3 KiB (javascript) 7.79 KiB (runtime) [orphan] 70 modules
runtime modules 3.24 KiB 5 modules
built modules 1.08 KiB (css/mini-extract) 25.1 KiB (javascript) [built]
  css modules 1.08 KiB
    modules by path ./src/github/ 528 bytes 2 modules
    modules by path ./src/oik-csv/ 369 bytes 2 modules
    modules by path ./src/oik-wp/ 51 bytes 2 modules
    modules by path ./src/oik-dashicon/ 156 bytes 2 modules
  javascript modules 25.1 KiB
    ./src/index.js + 20 modules 23.8 KiB [not cacheable] [built] [code generated]
    ./node_modules/classnames/index.js 1.3 KiB [built] [code generated]
webpack 5.69.1 compiled successfully in 5550 ms

I have no idea what the Skipping message means.

[bobbingwide]

The packages-update command changed the @wordpress/scripts version from 15.0.1 to 22.0.1.
22.0.1 doesn't appear to be released yet.

I can't find any documentation that helps me understand how I'm supposed to make use of the fact that the block.json files are copied to the build folder or the fact that .php files also get copied.
Should this make i18n/l10n easier? If so, what code changes should I be making to the .php?

Questions?

• Can a safely release the existing code without making any changes?
• What changes could/should I make in the future?
• Where is this documented?

The answer to the last question may be here... WordPress/gutenberg#25188

I think I should investigate these questions by attempting to update my https://github.com/bobbingwide/sb-starting-block plugin.

[bobbingwide]

What changes could/should I make in the future?

I updated sb-starting-block to deliver each block individually. Then I made the same changes as for sb-starting-block in #42.

Where is this documented?

This is yet to be developed. In the mean time, see the referenced issues.

Delivered in v2.2.1. Closing therefore.