Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Empty repeater is not empty if containing a file field #721

Closed
phh opened this issue Aug 25, 2016 · 16 comments
Closed

Empty repeater is not empty if containing a file field #721

phh opened this issue Aug 25, 2016 · 16 comments

Comments

@phh
Copy link

phh commented Aug 25, 2016

Expected Behavior:

The meta value of the repeater group to be empty

Actual Behavior:

Instead returning one entry in the array with a file_id field containing 0

get_post_meta(...) array(1)
  →array(1)
    'myprefix_file_id' => integer 0

Steps to reproduce (I have confirmed I can reproduce this issue on the trunk branch):

  1. Save a post without filling these data in
  2. Output the data of the meta - try to compare with version 2.2.1

CMB2 Field Registration Code:

add_filter( 'cmb2_meta_boxes', function( $meta_boxes ) {
    return [ 'prefix_my_repeater' => [
        'title'        => __( 'Fact boxes' ),
        'id'           => 'prefix_my_repeater',
        'type'         => 'group',
        'object_types' => 'post',
        'fields'       => [
            [
                'id'          => 'prefix_factbox_group',
                'type'        => 'group',
                'description' => __( 'Add multiple fact boxes to the page' ),
                'options'     => [
                    'group_title'   => __( 'Fact box {#}' ),
                    'add_button'    => __( 'Add another fact box' ),
                    'remove_button' => __( 'Remove fact box' ),
                    'sortable'      => true
                ],
                'fields' => [
                    [
                        'name' => __( 'Title' ),
                        'id'   => 'prefix_title',
                        'type' => 'text'
                    ],
                    [
                        'name' => __( 'Image' ),
                        'id'   => 'prefix_image',
                        'type' => 'file'
                    ],
                    [
                        'name' => __( 'Text' ),
                        'id'   => 'prefix_text',
                        'type' => 'wysiwyg',
                        'options' => [
                            'media_buttons' => false,
                            'teeny'         => true,
                            'textarea_rows' => 6
                        ]
                    ],
                    [
                        'name' => __( 'Link' ),
                        'id'   => 'prefix_link',
                        'type' => 'text_url'
                    ],
                    [
                        'name' => __( 'Link text' ),
                        'id'   => 'prefix_link_text',
                        'type' => 'text'
                    ]
                ]
            ]
        ]
    ] ];

    return $meta_boxes;
} );
@jtsternberg
Copy link
Member

jtsternberg commented Aug 25, 2016

Thank you for reporting!
Are you saying this is a regression? (and worked with 2.2.1?)

@phh
Copy link
Author

phh commented Aug 25, 2016

Correct. Worked with 2.2.1. Updated to 2.2.2.1 and it "broke". After we updated the client kept getting empty boxes (due for us checking for ! empty meta) and everytime they updated a post the empty boxes appeared on the post.

Tested on 2.2.2 and @dev and the same problem appears. So currently rolled back to 2.2.1.

@skrichten
Copy link

I'm having the same issue here. Does anyone have a workaround instead of having to roll back?

@tw2113
Copy link
Contributor

tw2113 commented Sep 13, 2016

No solutions that I'm aware of at the moment.

@phh
Copy link
Author

phh commented Oct 13, 2016

I will go through the commits the upcoming week one by one and report on which commit this bug appears. If it's simple enough I will suggest a pull request.

@tw2113
Copy link
Contributor

tw2113 commented Oct 31, 2016

Did you ever make any headway with this one @phh ?

@phh
Copy link
Author

phh commented Oct 31, 2016

@tw2113 Not yet :( Will test if the new update solves this problem or not.

@phh
Copy link
Author

phh commented Nov 29, 2016

As of 2.2.3.1 the issue is still occurring.

@phh
Copy link
Author

phh commented Dec 11, 2016

Found it. Seems like the last time it was working was after e0c7a19. In 69bf9ba it seems to break but I have no idea why.

@tw2113
Copy link
Contributor

tw2113 commented Dec 12, 2016

A git bisect could provide a definitive answer for what commit caused the breakage.

@phh
Copy link
Author

phh commented Dec 13, 2016

Finally! Seems like dba5776 broke it.

@tw2113
Copy link
Contributor

tw2113 commented Dec 14, 2016

Ick, anything revolving around '0' is an instant headache :)

@phh
Copy link
Author

phh commented Dec 14, 2016

True. Is there a reason for the file type to always have a value of '0'? How is normal file types saved? I guess these also have this '0' value?

@tw2113
Copy link
Contributor

tw2113 commented Dec 14, 2016

That one I'm going to have to defer to @jtsternberg

@ReidTC
Copy link

ReidTC commented Jan 10, 2017

Anything new on this? I am finding that it is still an issue. Making some things look unseemly on a project I'm working on.

@phh
Copy link
Author

phh commented Jan 12, 2017

Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants