Associative arrays as property value don't work.

[entr]

Thanks for really great plugin. It looked very promising and didn't disappoint at most. Experienced one issue that really bugged me while trying to create a custom property that needs to store several types of values.

Given:

<textarea name="<?php echo $options->slug; ?>[address]"><?php echo $value['address']; ?></textarea>

meta is saved, but looks like this (last row):

+---------+---------+------------------------+-----------------------------------+
| meta_id | post_id | meta_key               | meta_value                        |
+---------+---------+------------------------+-----------------------------------+
|    1211 |     413 | _edit_lock             | 1431414216:3                      |
|    1212 |     413 | _edit_last             | 3                                 |
|    1213 |     413 | _wp_page_template      | default                           |
|    1214 |     413 | _papi_page_type        | contact-page/class-tour-page-type |
|    1216 |     413 | _contact_maps_property | Googlemap                         |
|    1229 |     413 | address                | Sofia                             |
+---------+---------+------------------------+-----------------------------------+

As a result $value is always empty.

[frozzare]

Thanks for your issue! I have tested this and can confirm that this is a bug. Will fix this later today.

[frozzare]

I have investigate this and even if I could add support for this I don't think it's a good idea since that it would only work when you have array like ['address' => 'text'] and not [ 0 => ['address' => 'text'] ].

If you take a look at how the [repeater] is build it has a large update_value function (is smaller in 1.3.0) that will make the value that should be saved will be saved as it should. The repeater saves every row and every property as a own row int he database so you can search on it.

So for now you have to use update_value and load_value to save the values right. I will think about how this could be moved to papi_property_update_meta function in 1.3.0. But I think it's kind of hard to support all kind of situations, since you could add more values then just property value and property type value.

If you would like to be able to search in the database on your array values you have to do something like the repeater does. If you don't need that you could save a serialized array in the database.

public function load_value($value, $slug, $post_id) {
    return unserialize($value);
}

public function update_value($value, $slug, $post_id) {
    return serialize($value);
}

Hope that this helps you!

[entr]

Thank you for looking into this.

How do you feel about introducing a helper functions, say papi_input_name( [ $subprop ] ), that could be used instead of <?php echo $options->slug; ?> and takes into account if property is part of repeater or not. Having a optional parameter for use cases like mine where $subprop would be 'address'.

[frozzare]

So with this helper function the right html name would be returned?

Let's assume that options->slug is list and the child property slug is address would papi_input_name return papi_list['address']?

If so I think it's better to add a metod to Papi_Property class instead of a helper function that wouldn't know the options->slug.

<input name="' . $this->html_name( $subprop ) . '" />

[entr]

That sounds right, I guess 👍

[frozzare]

I will look into it, added a new issue for that #63