Legacy Documentation
Some elements of the Gutenberg plugin are defunct or no longer supported. Those are documented below.
The information below needs vetting.
Blocks and Larva
Individual block classes that use Larva templates should have a larva_data method that 1) sets a template property and 2) returns the "controller data", or an array of data that will be passed to the Larva template via PMC::render_template to populate the UI patterns with data.
See class-story-block-engine.php for an example of controller code.
Controlling Compatibility with PMC Plugins
In cases where functionality from existing PMC Plugins should be disabled on the block editor, use a filter as a feature flag to exclude or include functionality. This should also enable the logic to be controlled from within PMC Gutenberg. An example feature flag:
// In pmc-plugin {plugin_name} or theme
public function some_function() {
if ( apply_filters( '{plugin_name}_block_editor_skip', false ) ) {
return;
}
// ... other code
}Functions
PMC\Gutenberg\Meta::get_instance()->register_meta_from_configscan be used to register meta from a json file. By default it will crawl the SRC directory if not directory is passed as the param for that function. This function is currently used in the blocks, filter, slotfills, and sidebars enqueue functions which registers meta only when we need it.
Testing
See [/core-tech/gutenberg/testing](testing docs) for additional context here.
Configuring Gutenberg for Brands
Every brand's theme should have a plugins/_config directory which contains a class-pmc-gutenberg.php which
extends the pmc-gutenberg plugin. Modifications/configurations for a theme are done here.
Activating / Deactivating Blocks
Not all themes will use the same set of blocks. The plugin activates certain blocks by default (core blocks and a few common-use blocks), but others must be activated by the theme (for example, the story-influencers block is only relevant to Indiewire).
Themes can define a config filter for pmc_gutenberg_enable_block_editor to add or remove custom or core blocks and enable the Block Editor for post types.
The config array is an array of key/value pairs of the post types and enabled or disabled blocks, navbars, or sidebars to register. Additionally, a catch-all post type key of any can be used to globally enable or disable elements.
Defining a post type key with an empty array will enable the Block editor for that post type and inherit any defined any post type enable/disable configs. A post type key must be provided to enable gutenberg using the use_block_editor_for_post_type filter called in the Gutenberg::enable_block_editor function called on init.
Example Config
function return_config() {
return [
'any' => [
'enabled' => [ 'kicker', 'bottom-block' ], // Enabled for all enabled post types.
'disabled' => [ 'core/table' ], // Disabled for all enabled post types.
'filters' => [ 'custom-filter-name' ], // Custom filters.
'plugins' => [ 'custom-plugins-name' ], // Custom plugins.
],
'post' => [], // Gutenberg enabled.
'page' => [
'enabled' => [ 'page-header' ],
'sidebars' => [ 'page-sidebar-1' ], // Enables sidebar for pages.
],
];
}
add_filter( 'pmc_gutenberg_enable_block_editor', 'return_config' );Legacy Support
The updates above builds on top of the Gutenberg class and is backwards compatible with the legacy approach to activating and deactivating blocks which can be defined using the pmc_gutenberg_init_blocks filter to add or remove blocks via manipulating an array of block names that will be registered and enabled in the editor.
Configuring Individual Blocks
Blocks that require theme configuration make use data localized by the plugin that can be filtered by the theme. To see if a block contains configuration options, look for a localize_data method in its class in classes/blocks/class-block-name.php.
Additional information about how to add and retrieve block configs can be found here.
Configuring/Enabling Reusable blocks
- Enable the
wp_blockpost type. - Enable the
core/blockblock.