fwazeter

SVG is surprisingly complex because of the way SVG's are coded and WordPress's handling of the SVG format. It's less a Gutenberg/Block Editor issue and more of a 'WordPress doesn't like SVG' type issue. The reason WP doesn't natively support SVG is because an SVG file is just plain ole' XML - and as such, anything could be passed in the XML code leading to some pretty bad vulnerabilities.

However, Gutenberg DOES enable you to take advantage of SVG functionality and provides components necessary for you to do so in just about any variety you want. When I ran up against a similar problem in creating a list of custom SVG icons (there were 30+ options) a client could configure and display across different posts, rather than returning the SVG code itself what you want to use is a combination of:

Icon from @wordpress/components

SVG from @wordpress/primitives

and Path from @wordpress/primitives

fwazeter

Discover Handles

We need to look inside the wp_styles() object and wp_scripts() object (for js) to discover what's registered & queued. The value of the ["handle"] key will be the the name you input into the $handle var in dequeueing styles/scripts.

function discover_scripts() 
{
    // Registered styles
    var_dump(wp_styles()->registered);

fwazeter

This adds a block template that displays in the block editor of WordPress so a user can add information in a preset way to a template. With the Template Editor, by default it adds under "Post Content." However, this file cannot be overwritten when a user is using a wp_template custom post type - so might be a little awkward to use now. It also has no impact on the front end rendering.

It's also not a great idea to use it for things like post-title as it will render post title twice in the editor, which is potentially confusing.

function register_block_template() {
	$page_type_object = get_post_type_object( 'post' );
	$page_type_object->template = array(
		array( 'core/group', array( 'layout' => array( 'inherit' => 'true' ) ),

fwazeter

Overview

Author: Frank Wazeter Author URL: https://wazeter.com

WordPress 5.8 marks a big step towards Full Site Editing and using Block Themes vs. traditional (classic) themes powered primarily by PHP template files. However, using currently experimental features in production is extremely risky due the developmental nature. This code shows how a WordPress theme can support and mimic Gutenberg Plugin's templating system for the block editor/template editor, while not having a dependency on the Gutenberg Plugin itself. Most existing references or documentation have a dependency of some kind on the Gutenberg plugin to make it work.

If full site editing is only fully available in testing, why implement features now in a WordPress classic theme?

The future is undeniably wrapped around full site editing - that everything can be manipulated through blocks and corresponding