[wp-trac] [WordPress Trac] #32326: Improve Support for Structured Data

[WordPress Trac]

#32326: Improve Support for Structured Data
-------------------------+------------------------------
 Reporter:  dshanske     |       Owner:
     Type:  enhancement  |      Status:  new
 Priority:  normal       |   Milestone:  Awaiting Review
Component:  Themes       |     Version:
 Severity:  normal       |  Resolution:
 Keywords:  needs-patch  |     Focuses:
-------------------------+------------------------------
Changes (by joyously):

 * keywords:   => needs-patch


Comment:

 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

--
Ticket URL: <https://core.trac.wordpress.org/ticket/32326#comment:5>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform