Community Support Forums — WordPress® ( Users Helping Users ) — 2010-12-04T16:54:00-05:00 http://www.primothemes.com/forums/feed.php?f=4&t=637 2010-12-04T16:54:00-05:00 http://www.primothemes.com/forums/viewtopic.php?t=637&p=4969#p4969 <![CDATA[Re: Custom registration fields do not save input]]> Statistics: Posted by Jwrbloom — December 4th, 2010, 4:54 pm


]]>
2010-09-07T23:20:35-05:00 http://www.primothemes.com/forums/viewtopic.php?t=637&p=3030#p3030 <![CDATA[Re: Custom registration fields do not save input]]> You're VERY welcome.
~ I replied to your other thread as well.
Thanks for your patience.

Statistics: Posted by Jason Caldwell — September 7th, 2010, 11:20 pm


]]>
2010-09-07T23:10:06-05:00 http://www.primothemes.com/forums/viewtopic.php?t=637&p=3027#p3027 <![CDATA[Re: Custom registration fields do not save input]]>
Any chance you have time for a look here while I have your attention?

viewtopic.php?f=4&t=436

Statistics: Posted by DomainWorldAccess — September 7th, 2010, 11:10 pm


]]>
2010-09-07T23:03:12-05:00 http://www.primothemes.com/forums/viewtopic.php?t=637&p=3026#p3026 <![CDATA[Re: Custom registration fields do not save input]]> ~ 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.

Statistics: Posted by Jason Caldwell — September 7th, 2010, 11:03 pm


]]>
2010-09-07T22:56:38-05:00 http://www.primothemes.com/forums/viewtopic.php?t=637&p=3024#p3024 <![CDATA[Re: Custom registration fields do not save input]]>
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?

Statistics: Posted by DomainWorldAccess — September 7th, 2010, 10:56 pm


]]>
2010-09-02T14:02:05-05:00 http://www.primothemes.com/forums/viewtopic.php?t=637&p=2877#p2877 <![CDATA[Re: Custom registration fields do not save input]]> 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:
$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

Statistics: Posted by Jason Caldwell — September 2nd, 2010, 2:02 pm


]]>
2010-09-01T18:48:30-05:00 http://www.primothemes.com/forums/viewtopic.php?t=637&p=2861#p2861 <![CDATA[Re: Custom registration fields do not save input]]>

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?

Statistics: Posted by DomainWorldAccess — September 1st, 2010, 6:48 pm


]]>
2010-09-01T18:22:43-05:00 http://www.primothemes.com/forums/viewtopic.php?t=637&p=2860#p2860 <![CDATA[Re: Custom registration fields do not save input]]>
Will keep you posted.

Thanks for a great tool, and great support.

Statistics: Posted by DomainWorldAccess — September 1st, 2010, 6:22 pm


]]>
2010-09-01T09:18:47-05:00 http://www.primothemes.com/forums/viewtopic.php?t=637&p=2837#p2837 <![CDATA[Re: Custom registration fields do not save input]]> 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:
suhosin.post.max_name_length = 128

Or into your /wp-config.php file like this:
Code:
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?

Statistics: Posted by Jason Caldwell — September 1st, 2010, 9:18 am


]]>
2010-09-01T06:21:28-05:00 http://www.primothemes.com/forums/viewtopic.php?t=637&p=2835#p2835 <![CDATA[Re: Custom registration fields do not save input]]>
I will send a phpinfo link as requested...

Statistics: Posted by DomainWorldAccess — September 1st, 2010, 6:21 am


]]>
2010-09-01T00:43:25-05:00 http://www.primothemes.com/forums/viewtopic.php?t=637&p=2817#p2817 <![CDATA[Re: Custom registration fields do not save input]]> 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:
<?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/

Statistics: Posted by Jason Caldwell — September 1st, 2010, 12:43 am


]]>
2010-08-30T22:37:37-05:00 http://www.primothemes.com/forums/viewtopic.php?t=637&p=2766#p2766 <![CDATA[Re: Custom registration fields do not save input]]> 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

Statistics: Posted by DomainWorldAccess — August 30th, 2010, 10:37 pm


]]>
2010-08-30T14:40:26-05:00 http://www.primothemes.com/forums/viewtopic.php?t=637&p=2725#p2725 <![CDATA[Re: Custom registration fields do not save input]]> 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.

Statistics: Posted by Jason Caldwell — August 30th, 2010, 2:40 pm


]]>
2010-08-30T11:01:15-05:00 http://www.primothemes.com/forums/viewtopic.php?t=637&p=2694#p2694 <![CDATA[Custom registration fields do not save input]]> Statistics: Posted by DomainWorldAccess — August 30th, 2010, 11:01 am


]]>