Return URL to page w/ [s2Member-Profile /]

I’m using custom return URLs to direct members to a page where they can edit their profile after they’ve paid. The “Manage My Membership” page just uses the [s2Member-Profile /] shortcode. The page shows the editable custom profile fields that are accessible to that member.

When members access that page directly, they can edit the allowable fields just fine and all is well.

But, when they are directed to this page after a successful payment, saving the profile “clears out” 2 of my custom fields that are hidden and uneditable to users. The fields do not show up on the profile edit screen, but saving action sets them to null. I use these custom fields to track “counts” of allowed support tickets, so setting them to null is a big problem.

Because the hidden custom profile fields are NOT set to null if you access the page directly, I think it has to do with the “?s2p-v=” parameter that gets passed to the page after payment.

Any thoughts?

Thank you for reporting this important issue.

Because the hidden custom profile fields are NOT set to null if you access the page directly, I think it has to do with the “?s2p-v=” parameter that gets passed to the page after payment.

When you say hidden custom profile field, what do you mean by that? Are you using CSS styling for that, or are you making the field uneditable via this section of the Dashboard?

See: Dashboard -› s2Member® -› General Options -› Registration/Profile Fields

Hi Bruce – I do mean uneditable via the Registration/Profile Fields of the dashboard. I’ve tried both of these settings:

No (uneditable & totally invisible after registration)
No (uneditable & totally invisible, both during and after registration)

Same effect as described above.

I also should mention that my members are logged in BEFORE they get to the Authnet Proform for payment, so throughout the process I’ve described above.

Thanks

I also should mention that my members are logged in BEFORE they get to the Authnet Proform for payment, so throughout the process I’ve described above.

The pro-form doesn’t edit the user’s profile if he’s logged in. When he’s logged in, the pro-form is for payment only. The pro-form has profile fields only when also used for registration if the user is not logged in.

So what you’re saying is that a user that had already registered and had those custom profile fields with a value, after paying the upgrade, have those custom profile fields set to null?

Could you please try these? Knowledge Base » Common Troubleshooting Tips

Hi Cristián –

Yes, that’s correct. An existing, logged-in user with some custom profile fields (uneditable & totally invisible) goes to update/upgrade their membership. After successful payment the are redirected (using success=”/manage-my-membership”) to a page with [s2Member-Profile /] embedded. When they save their profile from the ‘manage-my-membership’ page, the custom profile fields are set to null. If they just go to the “manage-my-membership” page directly (without having been redirected after payment) and save the profile, all is good and the custom fields are unchanged.

Thanks.

I see… Is the user logged in after the upgrade? Could you verify that? I think they may need to log back in after upgrading the account.

Yes, the user is logged in after the upgrade. Since I can replicate the problem, I setup a test scenario where I the upgrade pro form did NOT have the custom redirect. It just gives the message “Thank you. Your account has been updated. — Please log back in now.” If the user logs back in following the link in the message OR logs out then logs back in and navigates over to the “Manage My Membership” page the custom profile fields are set correctly when they get to that page, but if they save the profile they are set to null.

Weird. So, if I then go in as an admin and reset their custom profile fields to the value they should have and the user goes back to the “Manage my membership page” and saves it, the counts remain as they should (are not set to null).

Thanks for testing that.

Could you confirm you tried these? Knowledge Base » Common Troubleshooting Tips

And please submit your site’s info. s2Member® » Private Contact Form

Thanks! After you do those, I’ll forward this to Jason to investigate.

I spent a while trying to sort this out, and just decided to re-code this functionality as core WordPress user meta fields (using get_user_meta(), update_user_meta()). This now works fine for my use case.