For the past few months, we’ve been focusing our efforts on making Carbon Fields fully compatible with Gutenberg. We’ve added API for creating dynamic blocks, so you can use the same familiar field definition syntax to create rich Gutenberg blocks.

Today we release Carbon Fields version 3 which is available for install via Composer:

composer require htmlburger/carbon-fields

Creating Blocks

In Carbon Fields v3, you will see a new type of container called block. It allows developers to define blocks, as follows:

<?php
use Carbon_Fields\Block;
use Carbon_Fields\Field;

Block::make( 'Flight' )
    ->add_fields( [
         Field::make( 'map', 'from' ),
         Field::make( 'date_time', 'departure_timestamp' ),
         Field::make( 'map', 'destination' ),
         Field::make( 'date_time', 'arrival_timestamp' ),
     ] )
     ->set_render_callback( function( $flight ) {
         ?>
            <p>
                Flight departs
                from <?php echo esc_html( $flight['from']['address'] ) ?> at
                <?php echo $flight['departure_timestamp'] ?>
                and arrives
                to <?php echo esc_html( $flight['destination']['address'] ) ?> at
                <?php echo $flight['arrival_timestamp'] ?>
            </p>
         <?php
     });

From the user’s perspective, here is how this process goes:

You can read more about the block container in the documentation.

post_meta vs block containers

post_meta and block containers are quite different in purpose, as well as the way they store data.

The post_meta containers allow the user to edit meta information below the post body and store that data in the wp_postmeta.

They work in a similar way as in the classic edit screen:

The block containers, on the other hand, are used for a fundamentally different purpose. The values entered inside are stored in JSON objects within the HTML comments in the post_body instead of the wp_postmeta table. This allows users to add multiple copies of each block.

Having cleared up the difference, we could say that block containers are more of glorified shortcodes rather than replacements for the post_meta containers.

Custom fields for post revisions

Carbon Fields v3 introduces custom fields for post revisions, as well. This feature allows users to compare different custom fields’ values in the revision browser. It also allows previewing changes on the front end which were made in the custom fields.

Being first-row spectators of the development journey of WordPress sparks our excitement about what the future holds. Meanwhile, we’ll keep giving our best to maintain CarbonFields as one helpful tool in the hands of fellow developers.

The post Introducing Carbon Fields v3 appeared first on Carbon Fields.

We at htmlBurger are excited about this change. We’re committed to maintaining Carbon Fields and making sure that it will play nicely with Gutenberg.

In order to achieve that we’re working on 2 fronts.

First, we’ll make sure that custom fields containers work flawlessly within the “Post Meta” boxes below the Gutenberg editor.

Update 2018-12-13: Carbon Fields v3 currently has release candidate. Please see the announcement here.

The post Plans for Carbon Fields and Gutenberg Integration appeared first on Carbon Fields.

What is Carbon Fields?

Carbon Fields is a library AND a plugin that provides tools to developers to create enhanced custom fields for posts, terms, users, themes etc. similar to ACF or CMB2. Being developer-oriented, Carbon Fields field definitions are made through PHP rather than a visual administration interface.

However, being a library, Carbon Fields is not eligible for upload into the WordPress plugin repository as mentioned by Mika Epstein as it’s aimed at developers and not end users.

Wait, if Carbon Fields is a library then how come it is already in the WordPress plugin repository?

Well, we got lucky.

The WordPress plugin repository has apparently always disapproved of libraries and frameworks being uploaded however they only started enforcing this in the past year or so and since Carbon Fields was first uploaded on the 27th of January 2016, we got approved.

So … how do I install Carbon Fields 2.0 – as a library or plugin?

We actually went back-and-forth between distribution as a plugin and only as a composer package multiple times during the development of 2.0. Eventually we came to the conclusion that we cannot ship 2.0 through the WordPress plugin repository because it contains a number of breaking changes.

Those changes would have resulted in broken sites because site administrators clicked the “Update” button.

Does this mean that Carbon Fields is no longer installable as a plugin?

It actually is installable as a plugin – just not through the WordPress plugin repository. We ended up splitting Carbon Fields into two – the main library and a barebones plugin loader (both installable through composer).

If you want to load the library you should use composer require htmlburger/carbon-fields – see the quickstart guide here

If you want to load the plugin you should use composer require htmlburger/carbon-fields-plugin (which in turn requires the library) – see the quickstart here.

This allows you to use Carbon Fields however you like and on whatever setup you have (even on Bedrock) and breaking changes will not be an issue since plugin updates will not be released in the plugin repository.

Unfortunately, this approach has a couple downsides as well:

1. You should use composer to manage Carbon Fields’ version and update it when security patches are released
2. You have to write your own version checking code to resolve conflicts between multiple active plugins or themes loading Carbon Fields at the same time.

In an ideal world …

… WordPress would have plugin dependencies or direct composer support for plugins and themes.

WordPress’ focus has always been the end user (which is why it’s so popular) and we understand that, however, we as developers feel a little left out. Composer has completely revamped modern PHP development but we can’t really take full advantage of that. Drupal, for example, has had plugin dependency support for years if not a decade already. PHP version requirements for plugins is apparently coming soon, but that’s not really enough, is it?

If you want to read more on the subject of libraries as plugins you can check out this article regarding CMB2 as they seem to have the same distribution pains.

The post Carbon Fields Distribution Woes appeared first on Carbon Fields.