• Resolved montrealist

    (@spectrus)


    There’s an issue with checkbox custom fields on my local machine install, with the latest version of the plugin active (I’ve just upgraded from previous version).

    Here’s how I reproduce:
    1. Add a new checkbox custom field through the admin interface (settings -> wp-members -> fields), make sure that “Checked by default?” is checked.
    2. Log in for any user, go to the members area page, click on “Edit My Information”, try to change the value of newly-created checkbox, save. The checkbox will stay checked no matter what.

    Has anyone else experienced this?

    Thanks.

    https://www.ads-software.com/extend/plugins/wp-members/

Viewing 4 replies - 1 through 4 (of 4 total)
  • Plugin Author Chad Butler

    (@cbutlerjr)

    There does appear to be an issue. If the user updates their info and unchecks the box, the correct data is stored in the database, but the checkbox remains checked. However, unchecking the checked by default checkbox on the user detail page on the admin side does result in displaying the box unchecked. So, it is a display issue on the front end user update process.

    Thanks for catching this. I’ll look into a fix.

    Plugin Author Chad Butler

    (@cbutlerjr)

    I was able to figure out the issue after looking into it.

    Essentially, the logic for determining if a displayed checkbox should be checked was missing one consideration. It was determining (1) if the checkbox should be checked by default AND (2) if the form had not been submitted. If the form had be submitted, then it used whatever the submitted value was (i.e. a user unchecks the box, submits the form, but there is an error that stops the process, the checked by default box would display unchecked, because it retains the user’s selection).

    This logic step did not consider what if the user was registered and is editing their information and had an unchecked value for the box. Obviously, without that logic, the box displays as checked regardless of what the user has selected (and what is stored in their user meta – since that is correctly recorded).

    The fix for this is quite simple. It involves changing this logic step (which is one line of code) in two places – once for the CSS forms and once for the legacy table-based forms. (If you only use one, and will not change, you only need to make changes to that one.)

    The changes are to wp-members-dialogs.php, which contains all of the code for generating the forms that display on the user front-end.

    If you user the default CSS forms, look for this code at line 656:
    if (!$_POST && $wpmem_fields[$row][8] == 'y') { $val = $valtochk = $wpmem_fields[$row][7]; }

    Change that to:
    if( $wpmem_fields[$row][8] == 'y' && ( ! $_POST && $toggle != 'edit' ) ) { $val = $valtochk = $wpmem_fields[$row][7]; }

    If you are using the legacy table based forms, the change is exactly the same, but at line 315.

    This change will be included in the 2.6.2 bug fix release which I expect will be released soon.

    Plugin Author Chad Butler

    (@cbutlerjr)

    Legacy form should actually be edited at line 312 (not 315)

    Thread Starter montrealist

    (@spectrus)

    Thank you very much for looking into this on such short notice!

Viewing 4 replies - 1 through 4 (of 4 total)
  • The topic ‘[Plugin: WP-Members] possible bug with custom fields’ is closed to new replies.