Download the PHP package golchha/wp-plugin-boilerplate without Composer

On this page you can find all versions of the php package golchha/wp-plugin-boilerplate. 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-plugin-boilerplate

WP Plugin Boilerplate

A structured WordPress plugin boilerplate with a schema-driven field engine, MetaBox system, and deterministic plugin architecture.

PHP Version Downloads


An opinionated WordPress plugin boilerplate for building long-lived plugins with explicit structure and predictable lifecycle behavior.

This project does not provide user-facing features and does not try to replace WordPress conventions, Git workflows, or existing development practices.

It exists to provide a constrained starting point for plugins that are expected to grow over time - where admin configuration, settings, frontend behavior, and lifecycle concerns tend to blur and accumulate accidental complexity.


Documentation

Goal Document
Build a plugin from this boilerplate HOW-TO-USE.md
Look up a field type or schema key FIELDS.md
Understand architectural decisions ADVANCED-TOPICS.md
Contribute a change CONTRIBUTING.md
See what changed CHANGELOG.md

Built-in Examples

The repository includes working reference implementations demonstrating how the field engine, settings system, and MetaBox integration are intended to be used.

Examples demonstrate:

See the example modules in:

These examples are intentionally simple and serve as a baseline for building more complex plugins.


Core Principles


Hook Registration (v1.6.3+)

The boilerplate uses a centralized Loader to register WordPress hooks.

Feature classes do not call add_action() or add_filter() directly.

Instead, hooks can be declared using one of two approaches.

Declarative Hooks

Classes may define a hooks() method.

Example:

The Loader reads this method and registers the hooks automatically.

Manual Wiring

For dynamic hooks or external handlers, classes may still register hooks explicitly:

Both approaches can be used together.


Design Goals

This boilerplate is intentionally opinionated.

It is designed to help developers build long-lived plugins without accumulating architectural debt.

The project prioritizes:

The goal is not to replace WordPress patterns, but to provide a structured starting point for plugins that are expected to evolve over time.


Settings System (v1.3+)

The settings layer is now a structured, extensible system.

Field Architecture

MetaBox Support (v1.3+)

The field engine now powers both Settings and MetaBox modules.

Meta and Settings use the same core field abstraction.

MetaBoxRepository (v1.5+)

MetaBox persistence must go through MetaBoxRepository.

Direct use of get_post_meta() or manual meta key construction is not supported.

Meta keys are automatically namespaced as:

{PREFIX}{BOX_ID}{FIELD_KEY}

Repository guarantees deterministic key ownership and collision safety.

Supported Fields

Text-based

Numeric & Boolean

Choice

Rich

Editor Field

The editor field is powered by WordPress wp_editor().

As of v1.6.4 the editor field is supported inside repeater rows.

The field engine automatically manages TinyMCE lifecycle events to ensure:


Repeater Field

The repeater allows structured, sortable nested data.

Features

Repeaters always store ordered arrays and never leak template markup into the runtime DOM.

Storage Guarantees (v1.3+)


Media Field

Stores attachment IDs only.

Supports:

Behavior adapts automatically based on multiple: true.

Admin validation uses WordPress core notice styles to report duplicate selections or invalid file types. Storage format remains unchanged.


Admin UI System

The admin interface is:

Example:

Available widths:


Folder Responsibilities

Directory Responsibility
src/Admin Admin UI, menus, and admin-only modules
src/Settings Settings tabs and option persistence
src/MetaBox MetaBox definitions, registry, and repository
src/Frontend Frontend/runtime behavior
src/Core Field engine, definitions, rendering, and support utilities
src/Lifecycle Activation and deactivation logic
assets CSS, JavaScript, and static assets
vendor Bundled Composer dependencies

Each directory represents a deliberate architectural boundary.


Stability Guarantees

Starting with v1.0:

Breaking these guarantees requires a major version bump.


Versioning

Semantic Versioning is followed:


Changelog

Please see CHANGELOG for more information on recent changes.


Security

If you discover any security-related issues, please email [email protected] instead of using the issue tracker.


Credits

See also the list of contributors.


License

This project is licensed under the GNU General Public License v2.0 or later (GPL-2.0-or-later).

WordPress is licensed under the GPL, and any plugin that runs within WordPress and uses its APIs is required to be GPL-compatible.

You are free to use, modify, and distribute this software under the terms of the GPL. See the LICENSE file for details.


If this boilerplate has been useful to you, you can support its development here: Buy me a coffee


All versions of wp-plugin-boilerplate with dependencies

PHP Build Version
Package Version
Requires php Version ^8.3
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 golchha/wp-plugin-boilerplate contains the following files

Loading the files please wait ...