add_to_prefix and serialize_data arguments don't work in submenu context

[danielbachhuber]

I'd expect setting add_to_prefix=false and serialize_data=false to save my group's child a standalone option. Instead, I saw my child value stored serialized with the group.

[mboynes]

This is intentional and documented. I didn't see the need for it at the time, and it seemed a tad dangerous (and would add option bloat). That said, I'm open to adding it -- can you explain your use-case so I can better understand why this would be beneficial? Thanks!

[danielbachhuber]

That said, I'm open to adding it -- can you explain your use-case so I can better understand why this would be beneficial?

Nothing too special — just wanted to store the option individually, so I didn't have to traverse the array to access it.

[mboynes]

I took a quick swing at this yesterday and recalled another "gotcha" that's worth documenting here: other contexts (post, term, user) use get_metadata() which includes the $single argument. Fieldmanager_Storable leverages this feature to store repeating fields using the same key. This would need to be reconsidered for submenus, which require unique option_names. Therefore, repeating fields could never set $serialize_data to false when used in a submenu context. We wouldn't be able to catch this on field construct, so the fields would have to be crawled on context construct and an exception thrown if a repeating field with unserialized data is found.

[danielbachhuber]

Ugh, just ran into this again :(

it seemed a tad dangerous (and would add option bloat).

I don't think this is valid, as it's the same amount of data being stored, regardless. In fact, serialization actually adds more data to be stored.

[mboynes]

I absolutely welcome a PR for this. The note I added on 1/6 highlights the biggest hurdle, which I've yet to have the motivation to tackle.

[danielbachhuber]

I absolutely welcome a PR for this.

Some day!

For the next time I run into this, here's the solution I came up with:

add_filter( 'fm_preload_alter_values', function( $values, $context ) {
    $toothpress_options = array(
        'google_maps_api_key',
        'google_site_verification',
    );
    if ( ! in_array( $context->name, $toothpress_options ) ) {
        return $values;
    }
    return get_option( $context->name );
}, 10, 2 );
add_filter( 'fm_submenu_presave_data', function( $data, $context ){
    if ( 'toothpress_configuration' !== $context->fm->name ) {
        return $data;
    }
    foreach( $data as $k => $v ) {
        if ( ! empty( $v ) ) {
            update_option( $k, $v );
        } else {
            delete_option( $k );
        }
    }
    return array();
}, 10, 2 );

It's less than ideal because it still leaves the group option around, but ¯_(ツ)_/¯

[danielbachhuber]

And I ran into this again! 😄

This time, I want to save my data to individual options so it's not so closely coupled to the presentation layer (thus given me the freedom to move fields around in the future).

[mboynes]

@danielbachhuber funny enough, I ran into this a week or so ago, too. I don’t have time right now to address it, but would be able to assist if you want to take the first stab at it. Otherwise, I’ll queue it up to work on when I have some time!

[danielbachhuber]

Yeah, maybe I'll finally take a stab at it 😄 Headed on vacation next week though.