Page 1 of 1

Lost Custom Registration Fields After upgrading to 3.5.7

PostPosted: March 31st, 2011, 10:55 pm
by dmasciangelo
After upgrading s2Member to 3.5.7 all custom registration fields for my users disappeared. When I view the wp-admin/users.php page I get an error message at the top of the page:

Warning: Invalid argument supplied for foreach() in /wp-content/plugins/s2member/includes/classes/users-list.inc.php on line 148

If I attempt to administer my custom registration fields at wp-admin/admin.php?page=ws-plugin--s2member-options I do not have the Add New Field link in the Custom Registration Field section and no custom fields display in the list.

Can this problem be corrected and can the the custom field data be saved?

Re: Lost Custom Registration Fields After upgrading to 3.5.7

PostPosted: March 31st, 2011, 11:39 pm
by Cristián Lávaque
Hi Angelo.

It sounds like something went odd with the upgrade, which could be causing the error you saw. Here, follow the instructions in this post, please viewtopic.php?f=36&t=247

If you didn't turn Deactivation Safeguards on, that may have caused the loss of custom registration fields. Double check that it's enabled here WP Admin -> s2Member -> General Options -> Deactivation Safeguards.

Please, let me know if that helps. :)

Re: Lost Custom Registration Fields After upgrading to 3.5.7

PostPosted: April 1st, 2011, 12:58 pm
by dmasciangelo
Hi Cristián, thanks for the response.
I looked at my ws_plugin__s2member_options field in the wp_options table and compared the custom_reg_fields sections of one site using 3.5.7 successfully and my site with the problem upgrade.

The problem site was being upgraded from 3.2.5 with had custom registration fields as a comma separated list rather than the new version's excellent options and UI for custom fields. The data for the custom reg fields still exists in the ws_plugin__s2member_options field. Here's a snippet of the format:
"custom_reg_fields";s:591:"*Alternate Email*, *Home Phone or Cell*, *Home Address*"

This is a significant difference from the custom reg fields format used in 3.5.7.

A couple questions:
1- Is there a way to convert the old format to the new and update the database to correct the problem?
2- If I delete the custom_reg_fields section from ws_plugin__s2member_options then re-add then in the General Options with the exact same field names, will the data in each user's profile be retained or will I be corrupting the user profile and making the problem worse?

Thanks!

Re: Lost Custom Registration Fields After upgrading to 3.5.7

PostPosted: April 1st, 2011, 1:14 pm
by Cristián Lávaque
Ah, I see what you mean. I'm glad you found what the problem was. Thank you for reporting it!

Please, since I don't know if making those changes would wipe the stored data, don't make them. I'm notifying Jason about this right now and he replies back within a day, normally.

Re: Lost Custom Registration Fields After upgrading to 3.5.7

PostPosted: April 1st, 2011, 1:25 pm
by dmasciangelo
Thanks, I'll await the word from Jason ... and tinker with it on my local dev site just to see what I can break :)

Re: Lost Custom Registration Fields After upgrading to 3.5.7

PostPosted: April 1st, 2011, 1:38 pm
by Cristián Lávaque
LOL nice. Have fun. :)

Re: Lost Custom Registration Fields After upgrading to 3.5.7

PostPosted: April 1st, 2011, 7:02 pm
by dmasciangelo
So, I got it working again. Steps to fix:

1 - Remove the custom_reg_fields array in the ws_plugin__s2member_options record in wp_options table. This allows the Add New Field link to appear in the General Options screen.

2 - Create all the custom registration fields in the General Options screen making sure to use the exact same values for the Unique ID field that were used in the previous array.

Steps 1 & 2 may not correct all custom fields though. The prior version allowed a much longer unique id string than the new version. The old unique id's that are too long need to be shortened. This causes a disparity between the custom_reg_fields definition and the data store for each user in the wp_usermeta table's wp_s2member_custom_fields value. The disparity prevents shortened unique id data to not be displayed in the admin Users screen.

Fixing this requires an easy update to the database. You run a query like the one below to replace the old field names to the shortened ones on each user. It is important you update the length of each field correctly or your array will be out of alignment and no data will display for the user in the Users admin panel. The field name length is the s:xx value, the xx must be correct for the new id.

Code: Select all
UPDATE wp_usermeta
SET meta_value = replace(meta_value, 's:52:"my_super_duper_extra_long_field_id_that_will_not_fit"', 's:11:"my_short_id"')
FROM wp_usermeta
WHERE meta_key = 'wp_s2member_custom_fields'; 

Re: Lost Custom Registration Fields After upgrading to 3.5.7

PostPosted: April 1st, 2011, 7:33 pm
by Cristián Lávaque
Great job, Angelo! And thank you for sharing your solution! :D

By the way, I just changed your rank to Experienced User. :)

Re: Lost Custom Registration Fields After upgrading to 3.5.7

PostPosted: April 3rd, 2011, 7:48 am
by Jason Caldwell
Looks like you've got it. Thanks for sharing that!
For anyone else having this issue, please take note.

This format was changed backed in s2Member v3.2.7. Backward compatibility was left intact up until s2Member v3.5+. If you are upgrading from s2Member v3.2.7 or prior, please install s2Member v3.3.2 first, as it includes an automatic conversion utility built into its configuration system.

So, all you need to do is upgrade to s2Member v3.3.2 first, then open your s2->General Options panel, and click Save. That updates your format automatically. Then, upgrade to s2Member v3.5+. You'll be fine.

You can grab old versions of s2Member here:
http://wordpress.org/extend/plugins/s2member/download/

Please understand that while we make every effort to maintain backward compatibility from one version to the next, if you allow your installation of s2Member to become too outdated, this can be the result. It's not that we wouldn't love to leave backward compatibility in place forever, but at some point a decision has to be made that old code is coming out, in order to optimize and move forward.

Under most circumstances, this backward compatibility would have been left in place for a much longer period of time. However, in this particular scenario, the routine handling conversions was a potential bottleneck, and therefore it was removed to further optimize the software in v3.5+.




This snippet was taken out of context, so it's not worth much.
But this is the routine that dealt with automatic conversions up until s2Member v3.5+.
Code: Select all
<?php
/*
Backward compatibility for "custom_reg_fields", which was re-formatted in v3.2.7 to a JSON encoded array of fields.
*/
if ($GLOBALS["WS_PLUGIN__"]["s2member"]["o"]["custom_reg_fields"] && !is_array (json_decode ($GLOBALS["WS_PLUGIN__"]["s2member"]["o"]["custom_reg_fields"])))
    {
        $fields = array (); /* Initialize the new array of field objects. */
        /**/
        foreach (preg_split ("/[\r\n\t;,]+/", $GLOBALS["WS_PLUGIN__"]["s2member"]["o"]["custom_reg_fields"]) as $field)
            {
                $required = (preg_match ("/\*/", $field)) ? 'yes' : 'no';
                $editable = (preg_match ("/\^/", $field)) ? 'no' : 'yes';
                /**/
                if ($field = trim ($field, "^* \t\n\r\0\x0B"))
                    {
                        $fields[] = array ("id" => $field, "label" => $field, "type" => "text", "options" => "", "expected_format" => "", "required" => $required, "levels" => "all", "editable" => $editable, "classes" => "", "styles" => "", "attrs" => "");
                    }
            }
        /**/
        $GLOBALS["WS_PLUGIN__"]["s2member"]["o"]["custom_reg_fields"] = json_encode ($fields);
        /**/
        unset ($une, $editable, $req, $required, $field, $fields);
    }
?>