bobbingwide/sb-starting-block

Starting point for a single block server side rendered block

Starting block

• Contributors: bobbingwide
• Tags: block, starting, scaffold, SSR, static
• Tested up to: 6.4.1
• Stable tag: 0.1.1
• License: GPLv3
• License URI: https://www.gnu.org/licenses/gpl-2.0.html

Starting point for server side rendered, internationalized and localized blocks.

Description

The Starting block plugin is a block plugin to be used as the starting point for future Server Side Rendered blocks. It includes a second block to demonstrate internationalization and localization of block plugins with multiple blocks.

Unlike some plugins, where all the blocks are delivered in build/index.js, the runtime components of each block are delivered separately. The delivered files are named with an entry point that reflects the block name. The entry points are defined in webpack.config.js

const defaultConfig = require( '@wordpress/scripts/config/webpack.config' );
module.exports = {
	...defaultConfig,
* 	entry: {
* 		'sb-starting-block': './src/starting-block',
* 		'second-block': './src/second-block'
	},
};

Runtime components

The runtime components for each block are defined in their block.json files.

eg for oik-sb/sb-starting-block, which is defined in src\starting-block, the block.json file contains.

* "editorScript": "file:../../build/sb-starting-block.js",
* "editorStyle": "file:../../build/sb-starting-block.css",
* "style": "file:../../build/style-sb-starting-block.css"

editorScript contains the JavaScript for the block editor editorStyle contains the CSS for the block editor style contains the CSS for both the front end and the block editor

An additional file suffixed .asset.php is produced for each entry point. Used during block registration, it lists the package dependencies for the block editor.

The build process requires wp-scripts v26.17.0 or later.

Internationalization and Localization

At build time wp-scripts copies each block.json file into a subdirectory of the build folder.

These files are not used in this version of the plugin.

Since the PHP code in this plugin registers the blocks using the original block.json file in the src folder the filename in each file: is specified as a relative file to the original block.json

This relative path to the run time JavaScript is different to the path to the localized strings for the block generated using npm run makejson.

To support localization, special logic is used to help WordPress locate this generated .json file.

Basically it converts something like src/starting-block/../../build/sb-starting-block.js to build/sb-starting-block.js.

• Internally WordPress converts this to its MD5 equivalent: cef7108f087faf9f40f070ee4caf3c90. This is used in conjunction with the languages folder to determine the name of the file containing the translations. ie languages/sb-starting-block-en_GB-cef7108f087faf9f40f070ee4caf3c90.json

For the second-block the editor script build file is build/second-block.js. MD5 is bb36a1c4786c1e80b3a16bcb761ccd83.json.

One would hope that in the future this special logic won't be necessary.

Installation

The purpose of this plugin is to provide the source code for a Server Side Rendered (SSR) block that is copied into an existing plugin where the new SSR logic replaces an existing shortcode.

You should not need to activate this plugin. If you do, it's just like any other plugin.

Screenshots

1. Starting block - rendered in the editor in the bbboing language
2. Starting block - settings, bbboing language
3. Second block - editor display, bbboing language

Upgrade Notice

0.1.1

Update for support for PHP 8.1 and PHP 8.2

0.1.0

Update for each block's components packaged separately.

0.0.1

Update for an internationalized / localized version with multiple blocks.

0.0.0

First version to be used to replace any [your name here] shortcodes in FSE themes

Changelog

0.1.1

• Changed: Add PHPUnit tests for PHP 8.1 and PHP 8.2 #4
• Changed: Update build files #3
• Changed: Updated wp-scripts #3
• Tested: With WordPress 6.4.1 and WordPress Multisite
• Tested: With Gutenberg 17.0.2
• Tested: With PHP 8.1 and PHP 8.2
• Tested: With PHPUnit 9.6

0.1.0

• Changed: Update language files #3
• Changed: Update build files #3
• Changed: Changes after npm run package-update #3
• Changed: Update server logic for multiple entry points #3
• Changed: Update src to help to demonstrate multiple entry points #3
• Changed: Add webpack.config.js for multiple entry points #3
• Tested: With WordPress 5.9.1 and WordPress Multi Site
• Tested: With Gutenberg 12.7.0
• Tested: With PHP 8.0

0.0.1

• Changed: Added oik-sb/second-block,#2
• Changed: Internationalized and localized into UK English and bbboing ( locale bb_BB ),#2
• Tested: With WordPress 5.8.1 and WordPress Multi Site
• Tested: With Gutenberg 11.5.1
• Tested: With PHP 8.0

0.0.0

• Added: First version of the server side rendered block,#1
• Tested: With WordPress 5.7.1 and WordPress Multi Site
• Tested: With Gutenberg 10.6.0-rc.1
• Tested: With PHP 8.0

sb-starting-block's Issues

Create a starting block for development of Server Side Rendered blocks

npx @wordpress/create-block is OK but...

1. I need to be able to start most blocks as Server Side Rendered
2. For some reason the build fails initially
3. The logic doesn't automatically add my internationalization logic to package.json
4. More often than not I need to add a block to an existing plugin

The current method requires

• a bit of fiddling to build the new plugin
• and then to copy the code into the existing block.

Would it be easier to start with a starting block that already has Server Side Rendering built in and copy/cobble that?
If so, what are the steps?
This issue is to attempt to find out.

Requirements

• A Server Side Rendered starting block
• That can be copied into an existing plugin
• Easily renamed ( eg change starting to my-block-name
• Then built and tested prior to modification for the real requirement
• I want the source of the block to be in a subfolder - since I may need to add more blocks

Proposed solution

• Copy the relevant source code from sb-post-edit-block - a simple SSR rendered block built most recently
• Rename to oik-sb/sb-starting-block. Note: the oik-sb block prefix is intentional
• Rename functions to have the prefix oik_sb_sb_starting
• Determine the steps to enable the build to work
• Test the results for both npm run dev and npm run build
• Test the copying of the source code into another plugin to create a new block
• Update the readme to document how this is done

Block functionality

• In the editor the block should be SSRed with "Starting block."
• On the front end the block should be SSRed with "Starting block."
• The block should have the standard wrapper created using get_block_wrapper_attributes()

NFRs

• It should support apiVersion: 2
• The block should have the standard HTML and CSS to allow styling - see get_block_wrapper_attributes() above

Update to the latest @wordpress/scripts package and rework as required

wp-scripts has been improved considerably since I created sb-starting-block.
It would appear that it now supports multiple blocks per plugin.
I first noticed this change when I updated the package in bobbingwide/oik-bob-bing-wide#45

Requirement

• Update sb-starting-block to benefit from improvements to wp-scripts from the @wordpress/scripts package
• Attempt to simplify / reduce the code needed to support internationalization
• Understand how to register each block so that only the required code is loaded for the blocks that are used.
• Understand what's needed to enqueue the required CSS in the block editor and on the front end.

Create another block for sb-starting-block: oik-sb/second-block

While converting oik, oik-bobbing-wide, oik-blocks, oik-css and other plugins to work correctly for multiple blocks registered from several block.json files and then to internationalize and localize, I discovered that I needed more code than originally developed for sb-starting-block.

Requirements

• sb-starting-block to deliver more than one block: oik-sb/sb-starting-block and oik-sb/second-block
• At least one should be server side registered ( oik-sb/sb-starting-block )
• Each block to be registered with block.json using apiVersion:2
• They should all be registered in the server
• And have a reasonable number of supports attributes, including color and typography.
• Each block should be internationalized, translated and localized for en_GB and bb_BB
• Consider how easy it is to rename the following when cloned from the template:
  • plugin name
  • plugin slug
  • text-domain
  • block prefix
  • prefix for server functions
• Code should be suitable for documenting the i18n / l10n approach.

Proposed solution

• Add oik-sb/second-block, originally built using npx @wordpress/create-block
• Update oik-sb/sb-starting-block
• Update sb-starting-block.php with i18n and l10n logic
• Add examples
• Change oik-sb/second-block - removing CSS and adding several supports attributes - with slightly different values from oik-sb/sb-starting-block.

Support PHP 8.1 and PHP 8.2. Test with WordPress 6.4.1

Update code to run without problems in PHP 8.1 and 8.2, with WordPress 6.4.1

See bobbingwide/bobbingwide#103

Add oik-nivo-slider/nivo block to be distributed to oik-nivo-slider

In order to test the oik-b2p "build to plugin" routine we need a new block.
This will be a block called oik-nivo-slider/nivo
This will be a server side rendered block to replace the prototype block developed as oik-block/nivo and delivered as part of the oik-blocks plugin.

See https://github.com/bobbingwide/oik-b2p/issues

Requirements

• Server side rendering to support the attributes already supported by the plugin. See https://www.oik-plugins.com/oik_shortcodes/nivo/
• Optional - Nivo functionality of the block to work in the editor.

Proposed solution

• This requires corequisite changes to the oik-nivo-slider plugin to implement the server side rendering - transforming the block attributes to the shortcode attributes.