wp-cli
`wp theme mod get --all` produces malformed output for non-tabular formats
The wp theme mod get --all command formats its output in a clever way (this is the first time I've seen this particular formatting, I'm not sure if it's used elsewhere) by listing the first level keys of a serialised option value as its own element.
Example:
+-------------------------+--------------------------------------------------------------------------------------------------+
| key | value |
+-------------------------+--------------------------------------------------------------------------------------------------+
| 0 | |
| background_color | ffffff |
| nav_menu_locations | => |
| primary | 39 |
| color_scheme | yellow |
| sidebar_textcolor | #111111 |
| header_background_color | #ffffff |
| background_image | |
| background_attachment | scroll |
| sidebars_widgets | => |
| time | 1458419959 |
| data | {"wp_inactive_widgets":["calendar-3","search-3","search-5","categories-2","recent-comments-3","p |
| | ages-2","calendar-2","archives-2","meta-2","search-2","text-2","recent-posts-2","recent-comments |
| | -2","rss-2","tag_cloud-2","nav_menu-2","nav_menu-4"],"sidebar-1":["search-7","tag_cloud-5"],"sid |
| | ebar-2":["search-7","tag_cloud-5"],"sidebar-3":null} |
| custom_css_post_id | -1 |
+-------------------------+--------------------------------------------------------------------------------------------------+
Observer that the primary element from the nav_menu_locations option, and the time and data elements from the sidebars_widgets option are displayed as their own sub-elements in the table.
This output works okay for the tabular output, but for other formats it's broken.
Example of broken CSV output:
key,value
0,
background_color,ffffff
nav_menu_locations,=>
" primary",39
color_scheme,yellow
sidebar_textcolor,#111111
header_background_color,#ffffff
background_image,
background_attachment,scroll
sidebars_widgets,=>
" time",1458419959
" data","{""wp_inactive_widgets"":[""calendar-3"",""search-3"",""search-5"",""categories-2"",""recent-comments-3"",""pages-2"",""calendar-2"",""archives-2"",""meta-2"",""search-2"",""text-2"",""recent-posts-2"",""recent-comments-2"",""rss-2"",""tag_cloud-2"",""nav_menu-2"",""nav_menu-4""],""sidebar-1"":[""search-7"",""tag_cloud-5""],""sidebar-2"":[""search-7"",""tag_cloud-5""],""sidebar-3"":null}"
custom_css_post_id,-1
I've actually never seen this one before either.
I agree this is broken. Not sure whether it's even a good idea to have this in the table format, as it is not a table anymore in this case (the concept of a "row" has been invalidated).
For a quick fix for now, the special syntax can stay in table format (in case someone actually uses that), but should be avoided for all other formats. For these formats, a simple 1:1 mapping from values to format entries is preferable.
Seems something based on the conversion of an array to that format that try to keep the nesting. Maybe for other format is enough a trim or define the behaviour for that cases and define a standard solution.
I can confirm the issue is present in the latest 2.4.0 version.
wp theme mod list +--------------------+-------+ | key | value | +--------------------+-------+ | nav_menu_locations | => | | menu-1 | 2 | | footer | 4 | +--------------------+-------+
the same command but JSON output
wp theme mod list --format=json
[{"key":"nav_menu_locations","value":"=>"},{"key":" menu-1","value":2},{"key":" footer","value":4}]qsu3495@qsandbox:/home/..../sites/qs-demo.qsandbox.com/htdocs$
OS: Linux 4.4.0-137-generic #163-Ubuntu SMP Mon Sep 24 13:14:43 UTC 2018 x86_64 Shell: /bin/bash PHP binary: /usr/bin/php7.4 PHP version: 7.4.6 php.ini used: /etc/php/7.4/cli/php.ini WP-CLI root dir: phar://wp-cli.phar/vendor/wp-cli/wp-cli WP-CLI vendor dir: phar://wp-cli.phar/vendor WP_CLI phar path: /home/...../sites/qs-demo.qsandbox.com/htdocs WP-CLI packages dir: WP-CLI global config: WP-CLI project config: WP-CLI version: 2.4.0
