Carbon Fields for WordPress Custom Field Development
WordPress Custom Fields Library ✨
At a glance
- What is it?
- Carbon Fields is a PHP library for adding custom fields to WordPress administration screens. It targets developers working with posts, taxonomy terms, users, comments, options, menus, and widgets, but the README delegates setup details to external documentation.
- Who is it for?
- Carbon Fields fits developers who need one custom-field layer across several WordPress content types and can follow its external documentation. It is a poor fit for projects needing a self-contained quickstart or for teams unwilling to accept a custom license.
- Can I use it commercially?
- Check first. The repository uses a licence we do not classify automatically, so read its LICENSE file before any commercial use.
- Is it still maintained?
- Yes. The repository last received commits 57 days ago.
- What is it written in?
- Mainly PHP, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 22, 2026, and from our analysis. They are not legal advice.
Editorial analysis
Why Carbon Fields Covers Several WordPress Object Types
Carbon Fields addresses a specific WordPress development problem: building custom field interfaces in the administration panel without treating each content type as an unrelated implementation. The README describes it as a developer-oriented library for custom fields across “all types of WordPress content,” then names post types, taxonomy terms, users, comments, options, navigation menus, and widgets as supported targets.
That scope is the main reason to consider the library. A site may need editable structured data on posts, configuration on an options screen, and fields attached to users or menu items. Carbon Fields presents those requirements as instances of one library rather than the documentation advertising separate products for each object. The intended users are PHP developers building WordPress administration features, including plugin or theme work that needs structured editor controls.
This is not a claim that Carbon Fields is a visual page builder. The documented purpose is custom fields, and the supported PHP baseline is PHP 5.6.20 or higher. The README does not state whether Carbon Fields stores values through WordPress core metadata, creates its own database tables, or provides validation, sanitization, access control, and conditional logic. Those implementation details should not be inferred from its support list.
The repository contains separate `core/`, `packages/`, `assets/`, `templates/`, and `tests/` directories. Based on that layout, the project has a PHP core, package-level components, browser-facing assets, rendering templates, and a test suite. The directory names indicate a divided codebase, but the README does not describe the boundaries or public API in enough detail to explain how a value moves from a form control to storage.
The Admin Data Path Behind Carbon Fields
The documented architecture is intentionally concise. Carbon Fields can be installed as a Composer package, and it creates custom fields in the WordPress administration panel for several object types. That points to two operational sides to the library. PHP defines and manages the fields available to WordPress, while browser assets contribute to their administration interface.
The repository layout supports that reading. `config.php` is the primary PHP-named configuration entry visible at the top level, `core/` contains the central library area, and `packages/` suggests that field types or related modules are separated into packages. `assets/` and `templates/` hold code and rendered output used by the package, while `webpack.config.js` and the development scripts show that browser assets are compiled with Webpack.
The `package.json` version is `3.6.11`, matching the newest listed release. Its `development` script sets `NODE_ENV=development` and invokes Webpack in development mode. Its `production` script changes `NODE_ENV` to `production` and invokes Webpack in production mode. The `build` script runs both modes, while `start` runs the development mode with `--watch`.
Even so, the README does not document the persistence path. It does not provide a field registration example, a retrieval API, a save callback, a storage table name, or a serialization format. A new user therefore cannot determine the exact data flow from the repository overview alone. The linked Quickstart and documentation site should be checked before adoption. Carbon Fields should not be selected on the assumption that it uses a particular WordPress storage convention without confirming that detail in those sources.
Installing Carbon Fields and Reaching the First Field
The README identifies Composer as the installation route and links to a separate Quickstart document in the `htmlburger/carbon-fields-docs` repository. It does not include the actual installation command, a WordPress plugin activation step, an example field definition, or a command that creates and displays the first field. Without those details, an executable installation example would risk sending readers down the wrong path, so this guide does not provide invented commands.
A first-use review should begin with the linked `documentation/10-quickstart.md` file. The reader needs to confirm the required Composer setup, where field definitions are placed, how those definitions are connected to a post type or another supported target, and which API retrieves saved values. The repository's `config.php` is relevant to that inspection, but its contents were not shown in the README, so no configuration keys can safely be taken from its name.
The browser asset workflow is clearer, although it concerns development rather than WordPress deployment. The repository declares `yarn.lock`, Webpack configuration, Babel configuration, PostCSS configuration, and JavaScript linting configuration. Its package scripts expose development, production, build, and watch modes. These scripts can rebuild Carbon Fields assets, but the README does not state whether consumers should run them when installing the Composer package or only when modifying the repository.
Before treating the library as production-ready, verify the runtime requirements as well. The README requires PHP 5.6.20 or higher, while the repository also contains JavaScript tooling that may impose a separate Node development environment. The `.nvmrc` file exists, but its selected version is not stated in the README. A contributor following the development setup must read `.nvmrc` rather than guess a Node version.
Supported WordPress Targets and Object-Level Constraints
Carbon Fields is most useful when a WordPress project needs custom fields attached to more than one kind of object. The explicit support list covers post types, taxonomy terms, users, comments, options, navigation menus, and widgets. That breadth can keep a project's field-definition approach consistent, particularly for a plugin that manages editorial metadata, site settings, and account-related data.
The same breadth creates questions that the short README leaves unanswered. Do comments and users receive identical field types? Can fields be conditionally displayed for different post types or taxonomies? Does the library define validation and escaping rules for each object? Are option fields global, page-specific, or grouped? The README gives no answers, so feature parity across every named object should not be assumed from the project description alone.
The package description calls Carbon Fields “developer-friendly,” but the README is too concise to assess the full development experience. It omits API examples, naming rules, lifecycle callbacks, migration guidance, and debugging instructions. It also does not discuss multisite behavior, capability checks, internationalization beyond the presence of a `languages/` directory, or compatibility with current WordPress release cycles. These omissions do not prove that the features are absent. They identify questions that the README cannot answer.
For a small site with one isolated editor field, adopting a general-purpose library may add more setup than required. A project-specific plugin or theme implementation that writes its own administration UI and retrieval code is the direct alternative in approach. It avoids adopting Carbon Fields as a dependency, but it also transfers field registration, persistence, validation, and compatibility work to the implementing developer. Carbon Fields becomes the preferable choice when that shared cross-content-type layer is worth centralizing.
Version 3.6 Releases and Upgrade Work
The repository is not archived, and its last push was on 2026-08-27. The latest listed release, `v3.6.11`, was published on the same date, followed by `v3.6.10` on 2026-08-26. A listed version, `v3.6.9`, is dated 2025-06-11. This release history shows changes concentrated in version 3.6, but the available release names contain no migration notes or behavioral details.
Upgrading therefore requires direct inspection rather than assuming patch releases are interchangeable. A developer should compare the changelog or release notes if available in the repository, review changes under `patches/`, and confirm whether the Composer dependency constraints in `composer.json` permit the intended version. The README does not include those Composer requirements, so it cannot establish the supported WordPress and PHP combinations for each patch release.
There is a second upgrade cost beyond applying a version. The project contains a `patches/` directory and a `postinstall` script that invokes `patch-package`. That script belongs to the JavaScript package workflow shown in `package.json`. It indicates patch application is part of local package setup, but the README does not say which dependencies are patched or whether the patched files are generated artifacts. Consumers should not run the browser asset build unless their contribution or release process requires it. The README describes end users installing the library as a Composer package.
The project lists a support page, a Gitter channel, and the GitHub repository. It also includes `CONTRIBUTING.md`, `DEVELOPMENT.md`, and `ISSUE_TEMPLATE.md`. Their contents are not included in the README, so the repository overview does not confirm response times, support scope, or the contributor workflow.
Carbon Fields License Metadata Needs Reconciliation
The repository metadata presents a licensing conflict that an adopting team must resolve from the actual files. GitHub classifies the repository license as “Other,” with a note directing readers to the `LICENSE` file. The visible top-level entry is named `license.txt`, and `package.json` declares `GPL-2.0`.
This does not justify a legal conclusion that the project is, or is not, GPL-2.0. It means the package manifest and repository classification do not give an unambiguous answer on their own. The content of `license.txt`, notices shipped with a release, and the version actually installed should be reviewed together. If Carbon Fields is redistributed or bundled with a WordPress theme or plugin, the relevant obligations need to be assessed for that distribution, but this review does not provide legal advice.
License review belongs early in adoption because it can affect packaging and upgrade decisions. Changing to a newer patch release should not be treated as license-neutral until its files are checked. Similarly, relying only on `package.json` can produce a misleading compliance record. The project-specific source for this review is `license.txt`, with release artifacts as the next place to confirm what ships.
Editorial conclusion
Carbon Fields fits developers who need one custom-field layer across several WordPress content types and can follow its external documentation. It is a poor fit for projects needing a self-contained quickstart or for teams unwilling to accept a custom license. Before adoption, inspect license.txt, confirm that the supported PHP version matches the deployment environment, and review the linked Quickstart for current installation and registration steps.
Frequently asked questions
What content types does Carbon Fields support?
The README lists post types, taxonomy terms, users, comments, options, navigation menus, and widgets as supported targets. It also describes support for all types of WordPress content without documenting object-specific limits.
How do I install Carbon Fields in WordPress?
The README says Carbon Fields can be installed as a Composer package. It does not include the command or activation steps, so those details must be taken from the linked Quickstart documentation.
Which PHP versions are supported by Carbon Fields?
The README states that Carbon Fields supports PHP 5.6.20 or higher. It does not provide a separate PHP requirement for each release.
Can Carbon Fields build custom fields for widgets and navigation menus?
Yes, the README explicitly lists navigation menus and widgets among the supported WordPress targets. It does not provide a field definition or retrieval example for either target.
What license does Carbon Fields use?
The repository classification says the license is a custom license that GitHub cannot classify, while `package.json` declares `GPL-2.0`. The README does not resolve this difference, so `license.txt` and the files in the installed release require separate review.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/htmlburger-carbon-fields)Was this useful?