Download the PHP package gebruederheitz/wp-gutenberg-blocks without Composer
On this page you can find all versions of the php package gebruederheitz/wp-gutenberg-blocks. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.
Download gebruederheitz/wp-gutenberg-blocks
More information about gebruederheitz/wp-gutenberg-blocks
Files in gebruederheitz/wp-gutenberg-blocks
Package wp-gutenberg-blocks
Short Description Helps you get your blocks on the road
License GPL-3.0-only
Informations about the package wp-gutenberg-blocks
Wordpress Gutenberg Blocks Helper
Helps you get your blocks on the road
Find it on packagist: https://packagist.org/packages/gebruederheitz/wp-gutenberg-blocks
Helps you with registering and rendering your custom Gutenberg blocks and acts as a common interface for libraries providing additional blocks.
Installation
via composer:
Make sure you have Composer autoload or an alternative class loader present.
Usage
Initializing the block registrar
Initialize the registrar singleton (usually in your functions.php
):
You may pass an alternative handle and path of your editor script to the constructor:
The script handle defaults to ghwp-gutenberg-blocks
, the script path to
/js/backend.js
. The script path is relative to the theme root
(get_template_directory_uri()
).
Setting allowed blocks
There are three ways of setting the blocks shown to the user in the editor. If
you want to skip all that and simply allow all block types, pass true
as the
first parameter to the registrar's constructor:
Dynamically through an array
You can also provide a list of allowed blocks via an array (it defaults to an empty array, initially allowing no blocks whatsoever):
Using a configuration file
Alternatively, you may use a YAML configuration file:
The value needs to be an array of strings and on the top level under the key
gutenbergAllowedBlocks
. You can then pass the file's path (relative to the
themes root as returned by get_theme_root()
or as an absolute filesystem
path) to the registrar's constructor as a string:
Even more dynamically through the filter hook
The third option is to use the filter hook to add allowed blocks (this is what
the DynamicBlock
class uses to automatically set up its availability). The
filter hook will always be called, even if you provide a custom list through
one of the methods above:
The parameter $allowedBlocks
will contain any blocks already allowed through
any of the other methods.
Registering a dynamic block
This all assumes you have defined the editor component, attributes etc. in your
editor script and registered the block there using wp.blocks.registerBlockType()
.
Your save
component returns null
– and this is where you want to register a
dynamic block that is rendered by PHP.
It is possible to allow a theme to override your default template partial for the block (even if your default partial file is outside the theme source directory) through the fifth parameter.
As an alternative you can use the factory method to create a Dynamic Block:
Available Hooks
Class constant | hook handle | type | description |
---|---|---|---|
BlockRegistrar:: HOOK_REGISTER_DYNAMIC_BLOCKS |
ghwp-register-dynamic-blocks | filter | Extend the provided array with an instance of DynamicBlock to automagically register that block. DynamicBlock does this for you when you call register() . |
BlockRegistrar:: HOOK_ALLOWED_BLOCKS |
ghwp-allowed-gutenberg-blocks | filter | A proxy for WP's own allowed_block_types . |
BlockRegistrar:: HOOK_SCRIPT_LOCALIZATION_DATA |
ghwp-script-localization-data | filter | Add items that your block requires to the localization data for the editor script. |
Development
todo