Download the PHP package sixach/wp-block-api without Composer

On this page you can find all versions of the php package sixach/wp-block-api. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.

FAQ

After the download, you have to make one include require_once('vendor/autoload.php');. After that you have to import the classes with use statements.

Example:
If you use only one package a project is not needed. But if you use more then one package, without a project it is not possible to import the classes with use statements.

In general, it is recommended to use always a project to download your libraries. In an application normally there is more than one library needed.
Some PHP packages are not free to download and because of that hosted in private repositories. In this case some credentials are needed to access such packages. Please use the auth.json textarea to insert credentials, if a package is coming from a private repository. You can look here for more information.

  • Some hosting areas are not accessible by a terminal or SSH. Then it is not possible to use Composer.
  • To use Composer is sometimes complicated. Especially for beginners.
  • Composer needs much resources. Sometimes they are not available on a simple webspace.
  • If you are using private repositories you don't need to share your credentials. You can set up everything on our site and then you provide a simple download link to your team member.
  • Simplify your Composer build process. Use our own command line tool to download the vendor folder as binary. This makes your build process faster and you don't need to expose your credentials for private repositories.
Please rate this library. Is it a good library?

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

Installation

You will need Composer installed on your computer in order to build and use this package.


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 Sixa_Blocks.

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, Sixa_Blocks\Block includes and performs block initialization and adds Sixa_Blocks\Block::register() to the WordPress action hook init.

Sixa_Blocks\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 Sixa_Blocks\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. Sixa_Blocks\WooCommerce_Block extends Sixa_Blocks\Block with a simple check in Sixa_Blocks\WooCommerce_Block::init() that prevents the block from being registered (i.e. Sixa_Blocks\Block::register() from being added in init) if WooCommerce is not installed and activated.

Other than that, Sixa_Blocks\WooCommerce_Block is identical to Sixa_Blocks\Block.

Basic Example

Sixa_Blocks\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, Sixa_Blocks\Extension includes and performs block initialization and adds Sixa_Blocks\Extension::register() to the WordPress action hook init.

Sixa_Blocks\Extension::register() is not implemented. In its most basic form, a simple block only needs to implement this function and perform Sixa_Blocks\Functions::register_extension_from_metadata according to the extension requirements.

Basic Example


All versions of wp-block-api with dependencies

PHP Build Version
Package Version
Requires php Version >=7.3
sixach/wp-snippets Version ^1.4.2
Composer command for our command line client (download client) This client runs in each environment. You don't need a specific PHP version etc. The first 20 API calls are free. Standard composer command

The package sixach/wp-block-api contains the following files

Loading the files please wait ....