Custom Fields
Re-Envisioned
Support MB Custom Table Serialized array for select_advanced saves incorrectly on front-end submission

This topic contains 5 replies, has 2 voices, and was last updated by  jcleaveland 1 week, 5 days ago.

  • Creator
    Topic
  • #15200
    Resolved
    jcleaveland
    Participant

    Hi,

    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!

Viewing 5 replies - 1 through 5 (of 5 total)
  • Author
    Replies
  • #15221

    Anh Tran
    Keymaster

    Hi,

    Do multiple meta boxes use different custom tables? If they use the same custom table, that might not work properly.

    #15244

    jcleaveland
    Participant

    Hi 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!

    #15259

    jcleaveland
    Participant

    Hi 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!

    #15271

    Anh Tran
    Keymaster

    Thanks 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.

    #15276

    jcleaveland
    Participant

    That’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!

Viewing 5 replies - 1 through 5 (of 5 total)

You must be logged in to reply to this topic.