Download the PHP package kuserich/wp-block-api without Composer
On this page you can find all versions of the php package kuserich/wp-block-api. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.
Download kuserich/wp-block-api
More information about kuserich/wp-block-api
Files in kuserich/wp-block-api
Package wp-block-api
Short Description Small collection of helpful interfaces and classes for the development of WordPress Blocks and Extensions.
License GPL-3.0
Homepage https://www.goeckeritz.xyz
Informations about the package wp-block-api
WordPress Block API
Small collection of helpful interfaces and abstract classes to make the development of WordPress Blocks and Extensions easier and more consistent.
Requirements
- PHP version 7.3 or greater
- WordPress version 5.7 or greater
Installation
You will need Composer installed on your computer in order to build and use this package.
- Add this package to the
requirefield in yourcomposer.json - Import
vendor/autoload.phpin your project
Usage
In Blocks & Extensions
Simply extend the block or extension class that fits the requirements of your package and extend all relevant interfaces (for extensions):
Development and usage is simplified if all blocks and extensions use namespace Kuserich.
Create an extension.json
Registration of extensions is done using a JSON configuration file akin to the block.json
file that WordPress Core uses.
Example:
Currently, extension.json uses the following fields:
name
Defines the name of the extension. This field is heavily utilized for asset handles and must be unique.
frontendScript
File handle used for the script that's only enqueued in the frontend. Use file: prefix if you are
passing a path to a local file. The path must be relative to extension.json.
frontendStyle
File handle used for the style that's only enqueued in the frontend. Use file: prefix if you are
passing a path to a local file. The path must be relative to extension.json.
script
File handle used for the script that's enqueued in the editor and the frontend. Use file: prefix
if you are passing a path to a local file. The path must be relative to extension.json.
style
File handle used for the style that's enqueued in the editor and the frontend. Use file: prefix
if you are passing a path to a local file. The path must be relative to extension.json.
editorScript
File handle used for the script that's only enqueued in the editor. Use file: prefix if you are
passing a path to a local file. The path must be relative to extension.json.
editorStyle
File handle used for the style that's only enqueued in the editor. Use file: prefix if you are
passing a path to a local file. The path must be relative to extension.json.
requires
An array of block names that the given extension requires. During asset enqueueing, the post content is check if at least one of the passed blocks is present. If it is not, the extension assets are not enqueued to improve performance.
In Projects
Each block and extension includes an init function that can be called to initialize
the class. No other function needs to be called.
As a Plugin
To run your block or extension as a standalone plugin, simply create a plugin file
(e.g. index.php) that calls the init function of your class.
As a package
Install your block or extension as a composer package and import vendor/autoload.php
somewhere in your project.
Next, simply call the init function:
Notice that there is no need to defer the init call to any WordPress hook in your project.
Blocks or extensions implement all relevant hooks.
Available Classes
In this section we elaborate on the available classes and interfaces and outline how we intend them to be used.
Abstract Class Block
A simple block class that includes the default implementation of a block class.
Particularly, Kuserich\Block includes and performs block initialization
and adds Kuserich\Block::register() to the WordPress action hook init.
Kuserich\Block::register() is not implemented. In its most basic form, a
simple block only needs to implement this function and perform register_block_type_from_metadata
according to the block requirements.
Basic Example
Notice the level 2 used in dirname. This is because the block class is inside a
directory in the root of the project (i.e. not inside the same directory as block.json).
Intermediate Example
Abstract Class WooCommerce Block
A simple block class that extends Kuserich\Block with a few additional convenience
functions to enable WooCommerce specific block initialization.
Particularly, for a set of WooCommerce blocks (i.e. blocks that require WooCommerce),
initialization and registration of the block is only necessary if WooCommerce is also installed.
In some cases the block might even produce a fatal error if WooCommerce is not activated.
For these instances, we intend to skip block registration.
Kuserich\WooCommerce_Block extends Kuserich\Block with a simple check in
Kuserich\WooCommerce_Block::init() that prevents the block from being registered
(i.e. Kuserich\Block::register() from being added in init) if WooCommerce is not installed
and activated.
Other than that, Kuserich\WooCommerce_Block is identical to Kuserich\Block.
Basic Example
Kuserich\My_WooCommerce_Block::register() is automatically not called if
WooCommerce is not installed.
Abstract Class Extension
A simple extension class that includes the default implementation of an extension. Particularly,
Kuserich\Extension includes and performs block initialization and adds
Kuserich\Extension::register() to the WordPress action hook init.
Kuserich\Extension::register() is not implemented. In its most basic form, a
simple block only needs to implement this function and perform
Kuserich\Functions::register_extension_from_metadata according to the extension requirements.