lzb.registerBlockType.args
Adds registration options that WordPress supports but the block builder has no screen for, such as block variations, transforms, or extra keywords for the inserter. The filter runs once per block as the editor loads, and what it returns is passed straight to registerBlockType() with no further processing.
Attributes
| Name | Type | Description |
|---|---|---|
blockArgs | Object | apiVersion, title, description, icon, category, keywords, supports, lazyblock, edit, save |
blockSlug | String | the block name, always prefixed lazyblock/ |
blockData | Object | the block record the plugin loaded from the database |
blockArgs.lazyblock is true on every block the plugin registers, which is how other code recognises one. blockArgs.edit renders the plugin's own editor component with blockData attached to it, so replacing edit or save replaces the block's editing and saving behaviour whole.
blockData carries id, title, slug, icon, keywords, description, category, category_label, supports, controls, code, style, script, styles, condition and edit_url. blockData.controls is the map of controls, keyed by id, which is what a handler reads to decide the attributes a variation should set.
Usage
wp.hooks.addFilter(
"lzb.registerBlockType.args",
"my.custom.namespace",
function (blockArgs, blockSlug) {
if (blockSlug !== "lazyblock/pricing-card") {
return blockArgs;
}
return {
...blockArgs,
keywords: [...(blockArgs.keywords || []), "plan", "tier"],
variations: [
{
name: "featured",
title: "Pricing Card, featured",
attributes: {
"plan-title": "Pro",
"plan-price": "$29",
},
},
],
};
},
);Attributes are not in blockArgs. The plugin registers them on the server, built from the block's controls, so adding an attributes key here is not how a field is added to a block. Add a control in the block builder instead. Because the returned object is the whole of the registration, build it by spreading blockArgs rather than from scratch, or the block loses its edit, its save and its supports.