Meta Box adds custom fields to every part of a WordPress site

The problem is that WordPress only edits posts and pages

The README states the motivation plainly. You want to add events, team members, testimonials, or listings to your WordPress site. But the standard editor only handles posts and pages. You need something more, but you don't want to overcomplicate things or slow down your site.

That is a well framed problem, because the standard way to solve it in WordPress is either a page builder with its own data model or a plugin that reimplements a chunk of the admin. Meta Box's position is that the data model should stay WordPress's and only the editing surface changes.

The plugin therefore works in the places WordPress stores things rather than inventing a parallel system. Custom fields go on posts and pages, on custom post types through the free CPT UI plugin, on taxonomies through MB Term Meta, on settings pages through MB Settings Page, on users through MB User Meta, and on comments through MB Comment Meta.

That last detail is what separates Meta Box from most of the field plugins. A directory site with a person, a category and a comment on the person needs the field on all three, and the answer here is a set of extensions that attach to the existing WordPress object types rather than a new taxonomy-driven model.

The claims are stated in three words in the README: lightweight with no bloat, flexible because it works with any theme or plugin, and fast because it uses native WordPress storage. And the storage point is the load bearing one, since it means the data ends up where WordPress and every other plugin already expects it to be.

Forty field types, cloning and repeatable groups

The field type list is what decides whether a project can be built without a custom field type.

Meta Box ships with 40 plus built-in field types: text, textarea, WYSIWYG, image, file upload, post select, checkbox, radio, date and time picker, taxonomy, user, oEmbed, and more. You can also create custom field types, and the documentation for that is linked from the same paragraph.

Two features cut across all of them. Most fields support cloning, which is the ability to add a second instance of the same field, and repeatable groups, which is the ability to add a set of fields as a group. Those two together are what turn a form of fixed fields into something that can model a variable number of things, which is exactly the case for the events, team members and testimonials in the README's opening example.

The developer-facing features are listed as a separate group. The API is described as lightweight, so it will not bloat your site, and modular, so you add only what you need. Native storage means WordPress meta tables are used by default for speed and compatibility, and it can be extended to custom tables for advanced setups through the MB Custom Table plugin.

There is Composer support, for modern PHP workflows, extensive actions and filters for customization, and the whole thing is integration-ready, meaning it works with any theme or plugin.

That last combination is the real answer to the overcomplicating concern. A plugin that writes into the native meta tables and exposes hooks is one another participant in the same ecosystem rather than a new layer on top of it.

The free core and the paid extensions around it

The business model is worth understanding, because it shapes what you get from the repository.

Meta Box Lite is the UI version of Meta Box that helps you manage everything visually, custom fields, post types, taxonomies and more, without touching code. That is the part you install from Plugins > Add New and the part the WordPress.org directory entry describes.

Meta Box AIO is an all-in-one plugin that bundles all free and premium extensions, giving everything from conditional logic to frontend submissions, custom tables to Gutenberg blocks in one package.

So the plugin you download is the framework, and the extensions around it cover the object types and the advanced cases. The README links the object type plugins directly in the features list, which is the clearest statement of how the pieces fit together.

The licence field in the repository listing is recorded as unknown, and the repository does not carry a LICENSE file at the top level, so the terms of the core plugin come from the WordPress.org plugin directory and the site rather than from the source tree. That is worth knowing before you read the code, since a commercial plugin with an open repository and an unusual licence arrangement is exactly the case where you should check the terms rather than assume.

The sibling products are listed at the end. Slim SEO, a fast lightweight and full-featured SEO plugin with minimal configuration. Falcon, a lightweight companion for making WordPress faster, cleaner and more secure. GretaThemes, free and premium WordPress themes. And Auto Listings, a car sale and dealership plugin.

How the code is organised and what it is built with

The repository layout is a WordPress plugin with a modern build on top of a traditional structure.

The entry point is meta-box.php at the top level, and there is a readme.txt, which is the WordPress.org plugin readme format used for the directory listing. The PHP source is split across inc/ and src/, with css/ and js/ for the assets, img/ for images, docs/ for documentation, and tests/ for the test suite. The.distignore file lists what should be excluded from a distribution build, which is the convention for keeping development files out of a release archive.

The build tooling is the current WordPress JavaScript stack rather than a hand-rolled setup. The package.json has @wordpress/scripts at 32.2.0, which provides the wp-scripts build and start commands the scripts use, @wordpress/icons for the icon set, and sass for the dashboard stylesheets. The build script clears the block editor build directory, runs wp-scripts build and then removes the generated RTL stylesheet, and the start script runs wp-scripts start for development. There are also separate sass scripts for the dashboard CSS, one to build it compressed with no source map and one to watch.

The PHP side has its own tooling. There is a composer.json and composer.lock, a phpcs.xml for coding standards, a phpstan.neon for static analysis, a phpunit.xml for the test suite.. The pnpm-lock.yaml and pnpm-workspace.yaml alongside the npm tooling show a mixed package manager setup, which is common in WordPress projects where the PHP side uses Composer and the JavaScript side uses a node package manager.

The AGENTS.md at the top of the repository holds agent guidance instructions, and the CHANGELOG.md is present locally even though the README points to the changelog on the site.

Where Meta Box is the wrong choice

The first limit is that a commercial product is involved. The core plugin is free and the paid extensions are where the object type support lives, so a project that needs user meta, comment meta and custom tables is looking at a paid licence. That is a fine arrangement for an agency or a client project and a poor one for a hobby project that needs one field on a taxonomy.

The second is that it does not solve the content modelling problem for you. The README's own framing is that you want to add events, team members or testimonials, and Meta Box gives you the fields to do that, but the post types, the taxonomies and the front end still have to be built. A page builder that includes listing templates may get there faster for a non developer, and a custom post type plugin with a front end may be a better fit for a developer who wants full control.

The third is the WordPress meta table as the storage layer. It is fast and compatible, and it is also the place where a very large site will start to feel the consequences of a table that every plugin in the stack can query. The custom tables extension exists for that reason, and moving to it is a migration rather than a configuration change.

The fourth is the version history in the repository, which needs reading carefully. The listed releases are 4.13.1 from 2018-01-08, 4.13.0 from 2017-12-28 and 4.12.6 from 2017-12-04, while the last push to the repository is on 2026-10-15 and the README describes 40 plus field types and a Gutenberg block editor build with @wordpress/scripts at version 32, which did not exist in 2017. The conclusion is that the tags in this repository are not the current release line, and the version you install from the WordPress.org directory is what the README describes. Anyone building from the repository needs to work out which state of the tree they want, and the README does not walk through that.

The fifth is the plugin ecosystem's general fragility. A plugin that writes to native meta tables and hooks into the admin is affected by every other plugin that does the same, and by every core release that changes the editor.

Editorial conclusion

Meta Box suits a WordPress developer who needs structured data attached to more than just posts, for example a directory site with events, people or listings, and who wants that data in the native meta tables rather than in a custom table. It is the wrong tool for a site whose content model is just posts and pages, since the standard editor already covers that, and it is the wrong tool if you cannot accept a commercial product with a free core and paid extensions. Before starting, read the requirements for your specific object type, because the taxonomy, user, comment and settings page support comes from separate extensions rather than from the core plugin.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. wpmetabox/meta-box on GitHub