Community Support Forums

Re: gradual demotion, custom capability or hidden field

2011-09-02T19:27:08-05:00

I'm very glad I could help you with this.

I think the update may affect the login.css file, I'm not sure. I hope we can improve the visibility setting for custom profile fields soon.

Statistics: Posted by Cristián Lávaque — September 2nd, 2011, 7:27 pm

Re: gradual demotion, custom capability or hidden field

2011-09-02T00:06:57-05:00

Cristián Lávaque wrote:
Because #registerform is not the selector for the pro-form, so the style is not being applied there.

Here's a tutorial on CSS selectors: http://css.maxdesign.com.au/selectutorial/

I'm guessing it's the same ID regardless of the installation, so I copied it from my tests website: #s2member-pro-paypal-registration-form

I hope that works.

Well, yes and no

The tutorial really didn't help much but your mention of "ID" made it a bit more obvious what I was looking for so I figured out with Firebug that besides the form identifier, the controls are named quite differently on the two forms.
On the wp reg form, the check box ID is: #ws-plugin--s2member-custom-reg-field-approved
On the s2 Pro Form, the check box ID is: #s2member-pro-paypal-registration-custom-reg-field-approved

Which makes sense in that the field is provided by a plugin for the wp form.

Anyway, the checkbox is now invisible on both forms although on the ProForm unlike the standard wp form, even though the checkbox is invisible, it still takes up a lot of space. Kind of funny but I actually prefer it as it really breaks the form from the submit section.

One question... Do you know if the Login.css file, which lives in the wp-admin/css directory, will be over written when wordpress is updated? I presume it will be. Another thing to remember

Many thanks for your assistance, not a chance in this world or the next that I would have gotten this far without the help.

DP

Statistics: Posted by man-O-media — September 2nd, 2011, 12:06 am

Re: gradual demotion, custom capability or hidden field

2011-09-01T13:56:12-05:00

Because #registerform is not the selector for the pro-form, so the style is not being applied there.

Here's a tutorial on CSS selectors: http://css.maxdesign.com.au/selectutorial/

Your pro-form's page gives me a 404 now, but I'm guessing it's the same ID regardless of the installation, so I ccopied it from my tests website: #s2member-pro-paypal-registration-form

Code:: #s2member-pro-paypal-registration-form #ws-plugin--s2member-custom-reg-field-approved, #registerform #ws-plugin--s2member-custom-reg-field-approved + label {display:none !important; visibility: hidden !important; color: transparent !important;}

I hope that works.

Statistics: Posted by Cristián Lávaque — September 1st, 2011, 1:56 pm

Re: gradual demotion, custom capability or hidden field

2011-09-01T00:58:58-05:00

Ahhhh, login.css.
I had it placed in style.css

Now that it is in login.css the control is indeed hidden but of course only in the standard wp registration form.

On my Pro form page "registerform" the code does not work yet using Firebug, I can see the code in the style.css which is loading with the Pro form.
Does not make sense to me at all...

DP

Statistics: Posted by man-O-media — September 1st, 2011, 12:58 am

Re: gradual demotion, custom capability or hidden field

2011-08-31T02:26:07-05:00

I checked wp-login.php's head and login.css and didn't find the line I gave you. Where did you put it?

Statistics: Posted by Cristián Lávaque — August 31st, 2011, 2:26 am

Re: gradual demotion, custom capability or hidden field

2011-08-30T19:41:51-05:00

Well, if you look at the Pro form now, the control is there and visible and my style.css is loaded with your code so something else is up.
I named the page name "registerform" just in case that was an issue.
The wp default register page evidently uses its own css sheet so it is no wonder that the code is not effecting that form.

DP

Statistics: Posted by man-O-media — August 30th, 2011, 7:41 pm

Re: gradual demotion, custom capability or hidden field

2011-08-30T18:39:38-05:00

Funny, I saved your registration page and added that line to the styles in the HTML head to test it and worked.

Statistics: Posted by Cristián Lávaque — August 30th, 2011, 6:39 pm

Re: gradual demotion, custom capability or hidden field

2011-08-30T18:14:03-05:00

Cristián Lávaque wrote:
Yeah, the ID I posted earlier is the correct one for the standard WP registration form. I also played with the styles a bit and I think I got one that will work for you: ...
I hope that helps.

Well, I do appreciate the help but I guess I must have something wrong as neither piece of code has any effect on either form. The approved check box is as visible as ever

When you say "put it in your css" you do mean style.css, yes?
I simply pasted both pieces at the end of style.css.

DP

Statistics: Posted by man-O-media — August 30th, 2011, 6:14 pm

Re: gradual demotion, custom capability or hidden field

2011-08-30T16:37:34-05:00

Thanks, DP.

Yeah, the ID I posted earlier is the correct one for the standard WP registration form. I also played with the styles a bit and I think I got one that will work for you:

Code:: #registerform #ws-plugin--s2member-custom-reg-field-approved, #registerform #ws-plugin--s2member-custom-reg-field-approved + label {display:none !important; visibility: hidden !important; color: transparent !important;}

I hope that helps.

Statistics: Posted by Cristián Lávaque — August 30th, 2011, 4:37 pm

Re: gradual demotion, custom capability or hidden field

2011-08-29T20:38:12-05:00

In the meantime I have figured out how to read data from the administrative notes field which coincidentally made me see another issue
I had not realized that when an auto demote happens that the EOT is also cleared which clears the basis I need for renewals.

So going backwards a bit... I actually need to do two things:
I need to maintain the approved status which looks like it will work either by hiding the checkbox on the registration form or by using the notes field but I also need to set a specific EOT.

I have been looking at viewtopic.php?f=4&t=2878&p=8621&hilit=specific+eot#p8621
Which discusses using a function in the background behind a pro form and then using a variable like rp=""

I have added my questions over there but essentially the question is, can I do the same with a button?

Many thanks again... DP

Statistics: Posted by man-O-media — August 29th, 2011, 8:38 pm

Re: gradual demotion, custom capability or hidden field

2011-08-29T19:22:30-05:00

OK... it is visible

Statistics: Posted by man-O-media — August 29th, 2011, 7:22 pm

Re: gradual demotion, custom capability or hidden field

2011-08-29T19:11:46-05:00

Ah, got ya.

Well, you can make it visible so I help you with the CSS selector to remove that field from the registration. Or you can leave it like that and then try making it visible in the profile page.

Statistics: Posted by Cristián Lávaque — August 29th, 2011, 7:11 pm

Re: gradual demotion, custom capability or hidden field

2011-08-29T17:35:20-05:00

Indeed...
Even though the site is not officially "live" we are getting occasional registrations so I while I am working on this, I hid the control.

But as noted, it is hidden everywhere so as admin I also can't edit its status.

I presumed you wanted to know the urls to determine the name of the form but I guess not.

Do you need me to unhide the field?

Many thanks, DP

Statistics: Posted by man-O-media — August 29th, 2011, 5:35 pm

Re: gradual demotion, custom capability or hidden field

2011-08-29T17:21:51-05:00

Got your email. Thanks!

I don't see the Approve field in either registration form, although it is in the HTML, so the style is actually hiding it.

I'm emailing you a screenshot of what I see.

Statistics: Posted by Cristián Lávaque — August 29th, 2011, 5:21 pm

Re: gradual demotion, custom capability or hidden field

2011-08-29T15:29:14-05:00

Could you post a link to your registration page? Or send it from this form if you want to keep it private http://s2member.com/contact

Statistics: Posted by Cristián Lávaque — August 29th, 2011, 3:29 pm

Re: gradual demotion, custom capability or hidden field

2011-08-28T15:58:42-05:00

Cristián Lávaque wrote:
You can create a style that applies to it in the registration form only, not the profile page. Put those styles in your CSS file and use the right selectors to pick just the login form. If you named the custom profile field "approved" then it would be something like:
Code:
#registerform #ws-plugin--s2member-custom-reg-field-approved {display: none; visibility: hidden;}

I hope that helps.

Well, I will preface with many thanks...
I understand the idea but don't seem to have luck with the implementation.

The field name is correct so that leaves the form reference.
Does #registerform specifically refer to the default wp reg form? That is what I am currently using.
If not, I don't have a clue what that default form would be named.

And related to that... I do plan to eventually switch to the pro free reg from once Jason gets the tab index number straightened out.
When using the pro form, is its name simply the page name?

That all said, what is the field name of the "Administrative Notes" field so I could check the string for data?

DP

Statistics: Posted by man-O-media — August 28th, 2011, 3:58 pm

Re: gradual demotion, custom capability or hidden field

2011-08-28T02:51:14-05:00

You can create a style that applies to it in the registration form only, not the profile page. Put those styles in your CSS file and use the right selectors to pick just the login form. If you named the custom profile field "approved" then it would be something like:

Code:: #registerform #ws-plugin--s2member-custom-reg-field-approved {display: none; visibility: hidden;}

I hope that helps.

Statistics: Posted by Cristián Lávaque — August 28th, 2011, 2:51 am

Re: gradual demotion, custom capability or hidden field

2011-08-28T00:00:01-05:00

Cristián Lávaque wrote:
You could hide it during registration with CSS or JavaScript.

Perhaps you can hide it with css but when I hide it, it is hidden on the registration form and it is hidden on the admin edit user page which makes it kind of unusable

In the css styles section of the s2 custom fields editing dialog I tried:

display:none; visibility:hidden
and as I say, that works but the control remains hidden everywhere.

So I tried
[s2If !is_user_logged_in()] display:none; visibility:hidden [/s2If]
[s2If !S2MEMBER_CURRENT_USER_ID] display:none; visibility:hidden [/s2If]

But neither seems to have any effect.

DP

DP

Statistics: Posted by man-O-media — August 28th, 2011, 12:00 am

Re: gradual demotion, custom capability or hidden field

2011-08-27T00:24:20-05:00

You could hide it during registration with CSS or JavaScript.

Statistics: Posted by Cristián Lávaque — August 27th, 2011, 12:24 am

gradual demotion, custom capability or hidden field

2011-08-26T10:20:36-05:00

Hi all...

For this organization site, new members must register and then they are manually approved after passing a background check. That approval needs to be attached to their profile and it should only be possible to change it manually.

The easiest and most obvious would be an "Approved" checkbox but it should always be invisible to the member which is not possible with the current version.
A close alternative is calling the check box something less obvious and have it visible during registration but invisible and not editable by the user after registration. The trick here is, after the register button is pressed, I need to be sure it is unchecked. I tried this (after_configure AND during_configure) in my s2-hacks.php but no luck so I am sure I don't have the code right:

Code:: add_action ('ws_plugin__s2member_after_configure_user_registration', 's2_set_approved_by_org'); function s2_set_approved_by_org($vars = array()) { if (!is_admin() && $vars['processed'] === 'yes') { $s2_custom_fields['approved_by_org'] = false; update_user_option($user_id, 's2member_custom_fields', $s2_custom_fields); } } ?>

Another idea is to use a custom capability which works great but even if a custom capability was added to a user at level 0, s2 clears the custom capability when the EOT passes and the user is demoted from a higher level back to subscriber.
I should add that while I understand why this happens, I find it odd as a custom capability added at subscriber level should logically stay in effect when demoted back to subscriber level.

And yet another way which I would be happy with is to add the word approved to the s2 administrative notes field where s2 notes the demotion data. Text in that field seems to be fairly non-volatile but how do I check that field for text?

The most basic idea is to use level 1 for approved users so when a level2 or level3 user (levels that can only be achieved if level 1 was manually given) gets demoted they demote to level1 and not subscriber.

Help?

DP

Statistics: Posted by man-O-media — August 26th, 2011, 10:20 am