Improve Support for Structured Data

[dshanske]

There has been discussion before on various types of structured data. WordPress has limited support for microformats and it is a long-standing part of WordPress.

New standards for structured data continue to appear, and there have been some proposals in support. However, different people want support for different things. I think there is a solution with more general appeal.

body_class and post_class add classes to the body and post containers.

What if they were superseded by two new functions with a broader scope?

body_attributes and post_attributes which could add any attribute from a provided array into the body and post containers? Most of the structured data works on an attribute of the tags it is attached to, be it class or property or otherwise.

The body_class and post_classes continue to work as they always have.

Newer themes could use the attributes function, which could remove hentry adding by default, for example, and transfer control of structured data back to the theme.

There is also the possibility, if it isn't going too far, of adding a similar function for the content container.

[obenland]

Why does Core need to support this? Why can't that be up to themes?

[dshanske]

The positive result of body_class and post_class have been adding css classes to those elements of a page, something that can be done by a theme and a plugin.

Microformats attach data as classes, other standards use other attributes. I don't think it should be WordPress dictating what is added as an attribute, but helping the pieces come together.

I'm fiddling with this as a proof of concept in plugin form to see how it might work in use.

[SergeyBiryukov]

Related: #32336

[obenland]

Core needs to be able to add and remove classes to/from these elements, but there is no direct need to be able to manage attributes. Without a Core use-case I'd probably consider it theme territory.

[joyously]

I researched this and wrote up my ideas in June 2017 (​https://slack-files.com/T024MFP4J-F5SFNUWG7-03f2820dfd) from the perspective of theme review. I have since written a theme that implements this idea of a function that allows manipulation of attributes on the HTML of a page. It would work much better if that function were in core, like other template tags, so that there is a single interface instead of different ones for each theme. Core does not use most of the template tags, so I don't see that as a barrier to adding one more.

As stated in the link, my proposal is

• add new function to core for outputting HTML attributes
• add a new keyword for add_theme_support() like 'microformats'
• update core to only add the hentry post class if no theme_support for 'microformats' (this assures back-compat)
• theme support for 'microformats' would involve
  • adding hentry class only on post types with dates
  • adding hfeed class to non-singular pages
  • using the new core function on all the HTML pieces so plugins can supply other details in a filter, while supplying the required ones (entry-title, updated, author)

I see this as one function, which takes a parameter of the html tag being output, and the attribute list, so that plugins and child themes can determine which one to modify. In my theme, it is very simple for a child theme to add classes or other attributes (like for JS data) without having to override the template files. I used the function on the html tag, the body, the various parts of the post, and anywhere else that I wanted to be able to dynamically add a class in PHP.

Here is my function. I'm sure it can be improved. It was written to allow class="xx yy" as a parameter, but that might be a bad way to go due to quotes.

/**
 * Provide a way to filter the HTML attributes being output
 */
function the_attributes( $tag, $attrs = array(), $echo = true ) {
	if ( ! is_array( $attrs ) ) {
		// This can mess up nested quotes, but wp_parse_args will mess up all quotes.
		$attrs = str_replace( array( '="', "='", '" ', "' " ),
			array( '=', '=', '&', '&' ), trim( $attrs, "' \"" ) );
	}
	$attrs = wp_parse_args( $attrs );
	$attrs = apply_filters( 'the_attributes', $attrs, $tag );
	$out = '';
	foreach ( $attrs as $attr => $value ) {
		if ( is_array( $value ) ) {
			$value = array_map( 'esc_attr', $value );
			$value = join( ' ', array_unique( $value ) );
			if ( ! empty( $value ) ) {
				$out .= esc_attr( $attr ) . '="' . $value . '" ';
			}
		}
		elseif ( ! empty( $value ) ) {
			$value = ( 'href' === $attr || 'src' === $attr ) ? esc_url( $value ) : esc_attr( $value );
			$out .= esc_attr( $attr ) . '="' . $value . '" ';
		}
	}
	if ( $echo ) {
		echo $out;
	}
	return $out;
}

This solution would impact these other tickets (that I know about):

• #28482
• #35978
• #26723
• #32336
• #32348

[dshanske]

I wanted to revisit this, four years later. I have evolved somewhat, as has WordPress.

​https://developer.wordpress.org/themes/getting-started/what-is-a-theme/

The handbook says that themes take content and data and display it. But for custom post types and data, the theme doesn't know what necessarily the data and content is. Standards like microformats, as well as schema, attach attributes such as class, rel, etc to things... creating a system where these things can be set and used by the theme is better than requiring every theme to know about custom post types.

You could say that Gutenberg solves this...by handling individual blocks, but this was about supporting it for thene elements, such as content, body, etc.