Serialized array for select_advanced saves incorrectly on front-end submission
Support › MB Custom Table › Serialized array for select_advanced saves incorrectly on front-end submissionResolved
- This topic has 5 replies, 2 voices, and was last updated 5 years, 10 months ago by
jcleaveland.
-
AuthorPosts
-
July 2, 2019 at 10:52 AM #15200
jcleaveland
ParticipantHi,
I have a post_type with several different MetaBoxes.
Each MetaBox is editable using the front-end submission extension.
One field in a contact information MetaBox is a select advanced and saves a serialized array to the custom table. This works as expected.
a:1:{i:0;s:5:"18063";}
When updating any field in any MetaBox outside of the contact information MetaBox, the array is re-saved to the custom table as a string.
s:22:"a:1:{i:0;s:5:"18063";}";
If I edit the select_advanced field again, the data is saved properly.
a:1:{i:0;s:5:"18063";}
This behavior is not replicated when saving data to a post_type with single MetaBox now when saving data to the post_meta table. Only when saving multiple MetaBoxes to a custom table and only when using front-end submission, back-end submission works as expected.
Any idea what could cause this?
Thanks!
July 3, 2019 at 9:39 AM #15221Anh Tran
KeymasterHi,
Do multiple meta boxes use different custom tables? If they use the same custom table, that might not work properly.
July 5, 2019 at 6:47 AM #15244jcleaveland
ParticipantHi Anh,
Yes, each of the MetaBoxes writes to a separate table.
I should also clarify that the issue is only present when the field is set to select_advanced and multiple is set to TRUE. When selecting only a single item, the string is recorded in the DB as expected.
Any thoughts?
Thanks!
July 6, 2019 at 3:07 AM #15259jcleaveland
ParticipantHi Anh,
I have an update.
I discovered that the issue was actually occurring for all front-end select_advanced or select fields with multiple set to TRUE regardless of whether there are multiple MetaBoxes or not.
I had come across this with another metabox and created a workaround that led me to believe it wasn't happening.
The workaround hooks rwmb_{metabox_id}after_save_post and strips the string notation off of the serialized array.
Like so:
function obh_update_group_primary_contact($post_id) { global $wpdb; $table = $wpdb->prefix . '_group_contact_info'; $result = $wpdb->get_row( "SELECT * FROM $table WHERE ID = $post_id" ); $primary_contact = $result->obh_group_primary_contact; $string_query = stripos( $primary_contact, 's:' ); if($string_query !==false) { $ass_array = preg_split('/^[s]\:([1-9][0-9]{0,2})\:\"/', $primary_contact); $string_1 = $ass_array[1]; $string_2 = rtrim($string_1,'";'); } else { $string_2 = $primary_contact; } if($string_2){ $wpdb->update( $table, array('obh_group_primary_contact' => $string_2), array('ID' => $post_id ) ); } } add_action( 'rwmb_obh_group_description_after_save_post', 'obh_update_group_primary_contact' );
As far as I'm concerned, this is solved for me. Please let me know if you uncover a better way to address it in core. I'm always happy to implement your updates.
Thanks for all your hard work and the tremendous plugins!
July 6, 2019 at 10:46 AM #15271Anh Tran
KeymasterThanks a lot for your debug info! I'm going to check it now and hopefully will get it fixed soon.
Updated: I recorded a video for this problem: https://www.loom.com/share/8ec338cc383b4917973967f27c177971. I couldn't replicate it. Can you see and let me know if I did anything different from your side.
July 7, 2019 at 2:22 AM #15276jcleaveland
ParticipantThat's basically it. The only difference is that I have several MetaBoxes per post type with several fields all writing to their own tables.
I also have several things hooked to save_post... there could be something in there causing the issue.
We can close this for now as I'm thinking it must be on my end somehow. I'll let you know if I discover anything else related to this issue.
Thanks again!
-
AuthorPosts
- You must be logged in to reply to this topic.