History and background
Carbon Fields was started as htmlBurger’s internal custom fields library in 2009. Back then, we were just starting our business and the state of the WordPress’s plugin ecosystem was not as developed as it is nowadays. So we had to build our own solutions for basic stuff like custom fields and theme options.
For a few years, we used the library internally. Throughout this time, we built thousands of clients’ projects based on it. We were gradually extending Carbon Fields so it became fully-featured tool comparable to other plugins in the field. By 2015, it Carbon Fields was rewritten twice(once to include Complex Fields and another time to use Backbone instead of jQuery). In 2017, we rewrote the plugin once again in order to use React.
Carbon Fields was released as a plugin at the beginning of 2016. We took this step for several reasons:
- We wanted to give back to the WordPress community. We believe that WordPress is one of the most important pieces of software of our time, and we wanted to help make it better
- We, as developers, felt that the WordPress platform needs more developer-friendly tools. WordPress’s core team hasn’t been prioritizing developers’ problems — they are instead focused on the end users. In all fairness: that is why WordPress is so popular. Carbon Fields(and WP Emerge for that matter) are our attempts to make WordPress a more developer-friendly web development platform
We’d like Carbon Fields to excel in a few aspects:
- Developer happiness – we’re after a plugin that is compelling for a competent developer rather than a hobbyist. That is why Carbon Fields ships as a composer package rather than a WordPress plugin
- An elegant and expressive client API – Carbon Fields provides a coherent API that is intuitive to use and allows building maintainable code – even when there are dozens of fields in a single container (example)
- Feature-richness – along with the usual features you’d expect from a custom fields plugin, Carbon Fields bundles:
- Gutenberg blocks support
- alternatives to ACF’s repeaters & flexible content (we have merged those and called them Complex field)
- theme options pages
- user meta
- comment meta
- term meta
- custom widgets meta
- menu items meta
- conditional logic
- multi-site network container
Comparison to ACF
Carbon Fields has similar feature-set to ACF, but is more developer-oriented.
- With Carbon Fields you define your custom fields via PHP code. With ACF, you would typically create custom fields via admin UI builder
- Carbon Fields is installed as a composer package within your theme or plugin. ACF ships as a WordPress plugin that you install separately from your theme or plugin
- With Carbon Fields, end users have less control over the site general setup. For example, they can’t disable or upgrade the library code. Additionally, custom fields and theme options definitions can’t be changed without touching PHP code
- With Carbon Fields, changes in your custom field definitions are part of your GIT history. ACF typically saves those in the database
- Carbon Fields has steeper learning curve than ACF. Once you get a grip on how to do stuff, things become quicker to setup and maintain
Disclaimer: any comparison living on our website would be more or less biased in our favor, so if you contemplate whether Carbon Fields is a good option for you, we encourage you to look for more neutral sources of information:
- Compare WP – Plugin Comparison – Content Type / Custom Fields
- Bill Erickson’s comparison of ACF, Carbon Fields and CMB2 at WordPress meetup Georgetown
- Carbon Fields Review and the related Reddit Discussion
We hope that our efforts on this project will make the life of WordPress developers a bit easier. Consider starring our GitHub repo if Carbon Fields is useful for you.