Dumping <wp:postmeta> using an attribute-based/less-verbose XML structure

[drzraf]

(maybe to postpone) Related to https://github.com/humanmade/WordPress-Importer/pull/148

<wp:postmeta> is usually exported this way:

<wp:postmeta>
   <wp:meta_key>_wp_page_template</wp:meta_key>
   <wp:meta_value><![CDATA[some-string.tpl.php]]></wp:meta_value>
</wp:postmeta>

(156 bytes)

CDATA are used for the meta_value, so that HTML entities would not be interpreted by the XML parser.

This commit makes the parser aware of a second short format where post's meta are expressed as attributes: <wp:postmeta meta_key="_wp_page_template" meta_value="some-string.tpl.php" /> (85 bytes)

This commit makes the dumper conditionnally output postmeta in a second, short, format where post's meta are expressed as attributes: <wp:postmeta meta_key="_wp_page_template" meta_value="some-string.tpl.php" />

[danielbachhuber]

I'm 👎 on this.

Although it can be frustrating the official importer/exporter are neglected, we need to follow the existing WXR format as exactly as possible. If/when WXR moves forward in the future, we can adopt the same improvements.

[drzraf]

Could we, please, keep this one open for the time being to let discussion take place?

I see at least two parts.

• First one introduces the use of attributes for postmeta. This is a breaking change which can't happen without at least: an --option and a wp:wxr_version increment (and a consensus among existing importers)

• Second one are not breaking WXR format and would (should?) be supported by any importer out there since any XML processor could legitimately do such node's rewrites anyway.

  • conditional use of CDATA[] and HTML entities
  • omitting empty CDATA[]
  • omitting empty empty meta value More exactly:

    <wp:postmeta>
    <wp:meta_key>foo</wp:meta_key>
    <wp:meta_value><![CDATA[]]></wp:meta_value>
    == <wp:meta_value></wp:meta_value>
    == <wp:meta_value />
    </wp:postmeta>

I know these changes may be done by external XML tools in the pipeline, but even then, it'd be sane if hints/advises/documentation could be provided by wp-cli document w.r.t.

[danielbachhuber]

Could we, please, keep this one open for the time being to let discussion take place?

https://core.trac.wordpress.org/ticket/22435 is a more appropriate place for this discussion. WP-CLI follows implementation guidelines set by WordPress core.