Custom registration fields do not save input

[DomainWorldAccess]

I have a strange and recurring problem with custom registration fields not always saving input. Is this a known bug?

[Jason Caldwell]

Thanks for reporting this.
No. It's not a known bug. Can you please elaborate a bit more on your experience?
Please update to s2Member v3.2.3 and report back with any additional findings for me.
If you can show me how to reproduce the issue, I'll be happy to have it corrected.
~ Much appreciated.

[DomainWorldAccess]

http://mstpta.com/mst/wp-login.php?action=register - Try one. I can send you a screenshot of what the backend shows if you like. The fields are appropriately mandated, requiring input to process registration. It's just that the data does not always make it to the database for some reason.

No errors in mysql or apache logs to help

I'm running pro

•Version: 3.2.3
•Stable tag: 3.2.3
•Framework: WS-P-3.0

[Jason Caldwell]

Hi there. Thanks for your patience.
I just created an account on your site.

All of the fields were received properly, except for:
Oldest enrolled MST student name *

Something tells me this could be a Suhosin configuration issue.
http://www.hardened-php.net/ ( just a guess at this point )

Please upload this code snippet to your server, and send me a link to it privately:

Code: Select all

<?php phpinfo(); ?>

Save this line into a PHP file with any name, and upload it to your web space.
Private contact form: http://www.s2member.com/contact/

[DomainWorldAccess]

That is possible. Suhosin is on the system. The odd part is the inconsistency with respect to which field will not save. There is no ryme nor reason to it.

I will send a phpinfo link as requested...

[Jason Caldwell]

Hi there. Thanks for the phpinfo() file.
~ Much appreciated.

I just took a look at the server config. I *think* the problem might be this:

1. This particular field name:
Oldest enrolled MST student name *

Ends up as a POST variable name of:
ws_plugin__s2member_custom_reg_field_oldest_enrolled_mst_student_name ( 69 chars long )

2. In your server configuration, Suhosin is configured with:
suhosin.post.max_name_length = 64 ( this is the default )
http://www.hardened-php.net/suhosin/con ... ame_length

Possible solutions:

So I would try placing a line into your php.ini file, like this:

Code: Select all

suhosin.post.max_name_length = 128

Or into your /wp-config.php file like this:

Code: Select all

ini_set("suhosin.post.max_name_length", 128);

If it turns out that this IS the problem, is this Suhosin's fault? No, not really. This is a shortcoming in the way s2Member deals with Custom Fields in the current release ( v3.2.4 ).

Ideally, s2Member would generate variable names that are NOT soooo long, and this would avoid the conflict with Suhosin all together. So thank you for reporting this. I'll be sure to address this in the coming release with Custom Field improvements.

The odd part is the inconsistency with respect to which field will not save. There is no ryme nor reason to it.

Gotchya. So maybe it's NOT Suhosin. Let's see if we can rule out Suhosin though, by increasing ( suhosin.post.max_name_length ). Please let me know if that has any impact on the problem.

On the other hand, it could be that you've been testing with different field names? The length of those POST variables, will change, depending on the description you provide, so this *could* be the explanation for what seemed like a random behavior?

[DomainWorldAccess]

I have changed the suhosin configuration as requested. Will keep an eye on it and let you know. I believe that may also explain some of the failures since there was originally another field with an even longer name.

Will keep you posted.

Thanks for a great tool, and great support.

[DomainWorldAccess]

On the other hand, it could be that you've been testing with different field names? The length of those POST variables, will change, depending on the description you provide, so this *could* be the explanation for what seemed like a random behavior?

To clear up my thinking on custom fields for the registration form: It dawns on me after reading your remark above that perhaps if a field name is changed, the data which had been associated with its prior position in the "string of fields" for lack of a better term, is no more... The field is completely rewritten. Is this correct?

Does the "string of fields" show up in the database?

[Jason Caldwell]

Thanks for reporting back on this topic.
~ Much appreciated.

s2Member stores all of the Custom Fields into the database as an array, inside a single meta key called "s2member_custom_fields". So a call in PHP like this:

Code: Select all

$fields = get_user_option("s2member_custom_fields");

would give you an array of all Custom Fields.

If you change the fields later, and the Profile for a particular User is updated, any OLD non-existent Custom Fields ( based on your configuration ) would be discarded automatically.

So s2Member handles this part gracefully. There is, however, room for improvement in the way s2Member receives POST input data on the registration form, and profile editing form. Improvements to Custom Fields are going to be released with s2Member v3.2.6 ( coming very soon ). We'll be releasing support for checkboxes, selects, radios, single line, multi-line, and these will all be configurable on a per-Level basis as well; maximizing flexibility. @TODO/COPY :: Custom Fields

[DomainWorldAccess]

Hi Jason - Thanks again for the reply.

First - it seems your Suhosin suggestion did the trick.

Second, the upcoming changes sound like EXACTLY like what we need for our PTA membership

May I ask (and I know we are now WAY off topic) - do you plan to create an export users capability which would be able to sort and filter based on custom field data?

[Jason Caldwell]

Thank you VERY much for reporting back on this topic.
~ Much appreciated.

May I ask (and I know we are now WAY off topic) - do you plan to create an export users capability which would be able to sort and filter based on custom field data?

No. But if I receive enough requests I'd be happy to add this to our list. That being said, I would recommend a full export of all Users into a single file. This is possible with s2Member Pro. Then bring that export file into an application like Excel, or get the free Open Office application ( very popular ), which can handle these sorting issues for you rapidly, and with greater control.

After you have Open Office, open the CSV export file provided by s2Member Pro,
with the "Calc" application that comes with Open Office.

[DomainWorldAccess]

Thanks again.

Any chance you have time for a look here while I have your attention?

viewtopic.php?f=4&t=436

[Jason Caldwell]

You're VERY welcome.
~ I replied to your other thread as well.
Thanks for your patience.

[Jwrbloom]

I'd vote for custom fields being written to the wp_users datatable, each with their own column, instead of wp_usermeta.