Download the PHP package middag-io/wp-boilerplate without Composer

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

wp-plugin-middag-boilerplate

MIDDAG's proposed architecture for a WordPress plugin. It is an installable, testable reference — not a prescriptive framework. It shows, end to end, how to compose MIDDAG's OSS libraries (framework + wordpress + ui + @middag-io/react) into a real plugin. You are free to follow all of it, take a single layer, or ignore React entirely.

Example domain: Widget — a minimal aggregate persisted in its own table, exposed over REST, listed on an Inertia/React page and configured through a native WordPress settings page.

Start a new plugin (composer create-project)

The fastest path — Composer scaffolds the project and the initializer rebrands it:

After Composer installs the dependencies it runs bin/init.php automatically (post-create-project-cmd): it prompts for the plugin's identity, rewrites every token across the tree, renames the main file, normalizes code style, and then DELETES ITSELF so the new project carries no scaffolding residue. The OSS library dependencies are left intact — the generated plugin keeps consuming them.

Cloned the repo or used GitHub's Use this template instead? Run the same initializer by hand:

The initializer is idempotent-safe and, in a non-TTY shell with no --answers, prints a notice and does nothing — so an unattended composer install never hangs.

Installation (fresh clone, no MIDDAG credentials)

The OSS libraries resolve from the public Packagist — no auth.json, no Satis.

Activate the plugin in wp-admin: the wp_mdgbp_widget table is created on activation, and the "MIDDAG Boilerplate" menu appears with the Widgets (React) and Settings (native) pages.

Quality:

The identity knobs (what bin/init.php rewrites)

Rebranding the plugin means changing five independent identities. bin/init.php does all of it; the table is the map of what changes if you ever do it by hand.

Knob Value here Kind Derives / appears in
slug (kebab) middag-boilerplate chosen extra.installer-name → installed folder, text domain, main filename <slug>.php, REST namespace (<slug>/v1), React mount id (<slug>-app), ui package name, .pot target, and the const prefix MIDDAG_BOILERPLATE = upper(slug)
PSR-4 namespace (PascalCase) Middag\WpBoilerplate\ → src/ chosen every class; and the Vite IIFE global (MiddagWpBoilerplate = the namespace concatenated)
short prefix (snake) mdgbp chosen (abbrev.) table mdgbp_widget, CPT mdgbp_note, cron mdgbp_sync, capability mdgbp_manage, option keys, and the uninstall const MDGBP_UNINSTALL_PURGE = upper(prefix)
display name MIDDAG Boilerplate chosen Plugin header name, admin menu + page titles
Composer package middag-io/wp-boilerplate chosen composer.json name, release-please config

The namespace and the short prefix are NOT derivable from the slug — both are free choices, which is why a naive find-and-replace on the slug alone leaves the mdgbp_* table/option/cap tokens and the MiddagWpBoilerplate Vite global behind. Use bin/init.php; it covers all five (plus the repo URL and optional author/description).

The repository name (wp-plugin-middag-boilerplate) ≠ the installed folder (middag-boilerplate): the wp-plugin- prefix disambiguates the repo within the org, and installer-name governs the install path.

The OSS library identities (middag-io/framework, middag-io/wordpress, @middag-io/react, and the Middag\Framework\* / Middag\WordPress\* namespaces) are distinct from the boilerplate's own tokens and are never rewritten — the generated plugin keeps depending on them.

The rule: src/ (PHP) vs ui/ (visual)

The UI is optional. A plugin WITHOUT a rich interface has neither ui/ nor src/UI/ — delete both folders and the plugin stays valid (Domain + WordPress + Api).

Two UIs, one menu (it is not 100% React)

The boilerplate shows both WordPress admin worlds under the same menu:

Where a proprietary product plugs in core + licensing

The boilerplate is strict OSS (TIER A): it depends only on framework + wordpress + ui. It never requires middag-io/core or middag-io/licensing (proprietary) — otherwise it would stop being installable by an external developer, and the CI gate (OSS boundary) fails the build.

A real MIDDAG product adds those tiers at two points, without touching the rest of the architecture:

In other words: the OSS↔proprietary boundary is a DI seam, not a fork.

Vendor isolation (a product concern, not demonstrated here)

This boilerplate does not run Strauss. Prefixing only Symfony DI would be incoherent: middag-io/framework exposes Symfony DI types in its public API (BootstrapInterface::configure(ContainerBuilder)) and is not prefixed along with them, so an app that prefixed only the DI would break the interface implementation.

Isolating the vendor for real (to coexist with other plugins that bundle a different Symfony) means scoping the entire graph — framework + Symfony + PSR — with PHP-Scoper in the product's build. That is a product-build concern, deliberately out of scope for this reference to keep it coherent and simple.

Middag\Framework collision across multiple plugins: same case — resolved by PHP-Scoper in the product, documented here, not demonstrated.

Demonstrates vs. Freedom

The boilerplate DEMONSTRATES: composition via WpBootstrap + ContainerFactory; identity via WpComponentContext; one class per layer; auto-discovery by suffix

You are FREE to: choose SCAN_DIRS/namespace; which blocks/shells to register; inject your own RequestAuthenticatorInterface; use the framework's async bus; add CPTs/routes/pages; or ignore Inertia/React and use a single layer. The libraries are a menu, not a mandate.

Lifecycle & data: activation, capabilities, uninstall

The plugin uses plain static WordPress hooks for its lifecycle — register_activation_hook/register_deactivation_hook → Plugin::activate() / Plugin::deactivate(). It deliberately does NOT wrap this in a "PluginLifecycle" abstraction: such a helper couples every plugin to subsystems it may not need (it registers a CronRegistrar unconditionally), dead weight for a plugin without cron. Static hooks keep activation explicit and cost-free — reach for a heavier abstraction only when a plugin actually needs it.

i18n: English-first

Every user-facing string is wrapped in a WordPress i18n call (__() / esc_html__(), text domain middag-boilerplate = the slug) and the msgid IS the English text — never a pre-translated literal. Translations live in languages/ as .po / .mo; regenerate the .pot with composer i18n:pot. English-first keeps msgids stable across locales and lets any translator start from the source string.

Release

release-please maintains CHANGELOG.md and the version from Conventional Commits, bumping two places in the main plugin file in the release PR:

The header needs the block-marker form, not an inline comment. WordPress parses the header literally — _cleanup_header_comment() strips only a trailing */ or ?>, never // — so an inline // x-release-please-version would corrupt the version to 1.2.3 // x-release-please-version in the admin plugin list and update checks. PluginHeaderTest guards this: it parses the header exactly like WordPress and fails if it is not a clean semver matching the const.

Roadmap

License

GPL-3.0-or-later.

All versions of wp-boilerplate with dependencies

PHP Build Version
Package Version
Requires php Version >=8.2
composer/installers Version ^2.3
middag-io/framework Version ^1.7.1
middag-io/wordpress Version ^1.6
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 middag-io/wp-boilerplate contains the following files

Loading the files please wait ...