To allow the parameters to be adjusted in the WordPress block editor, I created a JSON object that can be passed to the block editor. This specifies the parameters and also passes the SVG as a template so that the block editor can create an SVG using the parameters and the template.

The templates were initially so simple that a separate template engine didn’t seem necessary. I created a simple render function that could use a single regular expression to insert parameter values from the block editor into the template. It’s possible that using a more advanced template engine might prove worthwhile later.

To make it easier to add new patterns later, I placed the JSON object in a file in a separate folder in the plugin directory: svg-tpl.

The WordPress plugin file `svg-bg.php` reads all files in the template folder and passes the JSON objects as an array to the block editor.

function get_svgs(){
	$svgs = array();
	$files = scandir( plugin_dir_path( __FILE__ ) . 'svg-tpl' );
	foreach( $files as $file ){
		if( $file == '.' || $file == '..' ) continue;
		$file_info = pathinfo($file);
    	if ($file_info['extension'] !== 'json') continue;
	
		$svg_json = json_decode( file_get_contents( plugin_dir_path( __FILE__ ) . 'svg-tpl/' . $file ) );
		
		if( $svg_json->template === "file") {
			$svg_json->template = file_get_contents( plugin_dir_path( __FILE__ ) . 'svg-tpl/' . $svg_json->name . '.svg' );
		} 
		$svgs[] = $svg_json;
	}
	return $svgs;
}

function wp_svg_bg_enqueue_block_editor_assets() {
	global $wp_scripts;
	$svgs = get_svgs();
    // Localize the script with the SVG objects
    wp_localize_script('create-block-svg-bg-editor-script', 'svgObjects', $svgs);
}

add_action('enqueue_block_editor_assets', 'wp_svg_bg_enqueue_block_editor_assets');

The block editor now has a specification of the parameters and a template for the SVG. However, to create the SVG, it also needs to use values derived from those parameters. For example, the height of the Asanoha SVG is equal to √3 * dx (the width parameter).

Therefore, a property with JavaScript functions is also passed to the block editor. For the height of the Asanoha base element, the function `view.functions.svg_height` is passed, which calculates the height based on `dx`. When evaluating the function, the entire JSON object is also passed as the `data` parameter, so the function has access to all parameters in the JSON object:

{ "view ": {
  "parameters" : {
    ...
  }, 
  "functions" : {
    "svg_height": { "return Math.round( data.dx.value * Math.sqrt(3));" }
    ...
  }
}

The complete setup for the block editor to generate a custom SVG can be seen in the file `svg-tpl/asanoha.json`

Now that the JSON object can specify which Inspector controls can be configured, the `edit-block` function can be created.

First, a select box is filled with options corresponding to the names of all JSON files found in the `svg-tpl` folder. Initially, I only had “Asanoha,” but the intention is to add more patterns. Based on the JSON object selected in this dropdown, controls are added to the panel in the Gutenberg Inspector controls. The parameter `dx`, as defined in `asanoha.json`, has the type `range`. This means the `edit` function adds a `RangeControl` to the panel. Other properties of `dx` are used to further configure the `RangeControl`, such as minimum and maximum values.

In addition to the `range` type, `edit.js` currently recognizes the types `string`, `select`, and `colorpanel`. These allow corresponding controls to be added. If the type is not recognized, it is ignored.

Once the necessary parameters are configured, the final SVG can be generated using the `renderTemplate` function. Initially, a template engine like Mustache seemed logical, but Copilot suggested a simple regex that works for now. Since this render function cannot recognize functions, the function results are explicitly placed in intermediate variables so that only variables need to be replaced during rendering, not functions evaluated.

I extended the JSON objects for the patterns with a `presets` property, an array containing groups of parameter presets. This shows that small changes to the parameters can result in significantly different appearances for the pattern. SVGs with these presets get an additional dropdown in the Inspector controls.

To distinguish them, I gave the preset groups names, often as far-fetched as Asanoha.

What should happen to the SVG after rendering? SVGs can be included in a webpage in various ways. In principle, the SVG could be saved as a file (e.g., in `wp-uploads/`), and that file could then be selected as a background image. However, this is not without issues because WordPress does not allow SVG uploads without modification.

Alternatively, an SVG can be included directly in the HTML and even used as a background image via an inline CSS style rule like the one below. This also saves an additional request to the server.

background-image: url(data:image/svg+xm, 'urlencoded svg data'). 

By converting the SVG into an inline style rule, it can be added to the `blockProps` of the Gutenberg block in both the `edit` and `save` functions.

// get the resulting svg by rendering the template and parameters
const svgResult = renderTemplate( mytemplate, myview );

// URL encode the svg
const svgDataUri = `data:image/svg+xml,${ encodeURIComponent(
        svgResult
) }`;

// Add the encoded svg as an inline css background rule
blockProps = useBlockProps( {
        style: { backgroundImage: `url("${ svgDataUri }")` },
} );

Adjusting parameters will immediately result in an updated CSS background style, so the Block Editor updates the background in real time, as intended.