Added a 'raw' format to the option get command

[shawnhooper]

Fixes: #165

Adds a --format=raw response to the wp option get command that returns the value as stored in the database. Used if you want to get the an option in PHP serialized format.

NOTE: I used the $wpdb->get_var() command instead of serializing the $value returned from get_option because the latter threw an error when running PHP CodeSniffer:

WARNING | serialize() found. Serialized data has known vulnerability problems with Object Injection. JSON is generally a better approach for serializing data. See https://www.owasp.org/index.php/PHP_Object_Injection

[swissspidy]

A direct database query won't work if an external database cache is involved, because then get_option() goes straight to use wp_cache_get() and the same value in the db could be stale or even non-existent.

WordPress provides a maybe_serialize() that we could use here. Worst case we'll have some PHPCS warnings to suppress :-)

[danielbachhuber]

A direct database query won't work if an external database cache is involved, because then get_option() goes straight to use wp_cache_get() and the same value in the db could be stale or even non-existent.

What if we called it --format=db? I think it's more clear than --format=raw too.

[swissspidy]

A direct database query won't work if an external database cache is involved, because then get_option() goes straight to use wp_cache_get() and the same value in the db could be stale or even non-existent.

What if we called it --format=db? I think it's more clear than --format=raw too.

While still using a direct database query? Then that sounds more like --source=db to me. Also noting that this would be circumventing any WordPress filters hooked into get_option.

[danielbachhuber]

Hm, maybe this enhancement is a bad idea then...

[swissspidy]

Alright, so wp option list already does raw SQL queries (which makes sense, there is no other way to get a list of all options), and has an --unserialize flag to unserialize the raw option values if needed. So that makes my point about the db query less relevant. So we could just proceed with this perhaps?

It would be roughly equivalent to wp option list --search="rawoptionname" --fields=option_value

Alternatively, if we do

$value = get_option( $key );

if ( 'raw' === Utils\get_flag_value( $assoc_args, 'format' ) ) {
	return maybe_serialize( $value );
}

the only drawback is that the option value that could be filtered by a plugin, so it might not exactly match what's in the db.

[danielbachhuber]

I'm leaning towards wontfix. I don't think the original use case is all that common. When it's necessary, the user can use $wpdb to fetch the raw value.

@johnbillion Thoughts?

[johnbillion]

I think I opened my original issue because wp option list allows you to see a raw value but wp option get does not. In an interactive terminal it's certainly preferable to type wp option get foo rather than wp db query "SELECT option_value FROM wp_options WHERE option_name = 'foo'".

[danielbachhuber]

This works fine too:

$ wp option list --search=widget_pages
+--------------+--------------------------------+
| option_name  | option_value                   |
+--------------+--------------------------------+
| widget_pages | a:1:{s:12:"_multiwidget";i:1;} |
+--------------+--------------------------------+

[swissspidy]

Still leaning towards wontfix here?

[danielbachhuber]

Still leaning towards wontfix here?

wontfix would be my preference

[swissspidy]

OK let's close this as a wontfix then.

@shawnhooper Thanks nonetheless for your contribution!