How to update the options table for a widget

Question

Each widget has a row in the options table with values for title and other fields. Is there any way we can update those values outside the update function?

For example, here are some values for a sample widget:

a:2:{i:2;a:23:{s:5:"title";s:19:"Widget Title";.....

now I want to update the title to another value in the function widget($args, $instance) and save the value to the database.

I found that options API can handle something like this, but I am not sure if this is the correct way and how to update the info for that specific widget.

// Update the value of an option that was already added.
update_option( $option, $newvalue );

Answer 1

An array will be serialized when saved to the DB. If you want to update a key to the array, you need to

• Fetch the option first
• Apply modifications
• Update the option with the updated array values

so in your example if you fetch the option, you should get a multidimensional array where you have a key => value of [title] => Widget Title you would update that title key with your new value and then update back your option.

Something like this

$my_option = get_option( 'your_option_name' );

now let's say your key is in the first dimension of the array, then you update your value there.

$my_option['title'] = 'New Widget Title';

and finally you update your options back to the DB.

update_option( 'your_option_name', $my_option );

Answer 2

The widget() method doesn't seem like a good choice for such operation, since it handles display of the widget. The update() method is where you typically manipulate the widget instance, in that case you don't have to explicitly save it since base class takes care of that.

In more general view what you are seeing is serialized data. Anything you save to option that isn't string already gets converted into such serialized string for storage. You can change it, as long as you are sure that's what you are actually want to do.

As long as you stick to Options API, it will transparently unserialize data on retrieval and serialize on save.

If you do this directly you will have to handle this yourself.

Simply changing serialized string breaks it, since the format depends on capturing length of data and mismatches stop it from working. That is very typical mistake in migrations, when people search/replace strings without accounting for this.