[jkd]

Yeah, I kinda figured that was the reason for the !important settings.

Regarding the custom style sheet…. if the plugin is upgraded using the instructions to disable, delete, reinstall the new version, wouldn’t that include the removal of the custom style sheet as well? Or maybe I don’t fully understand/appreciate the value of having that custom style sheet?

[jkd]

It seems all the css button settings for eMember are set with !important. This makes it intensive to override them in our child-themes.

Question: Wouldn’t it be better if the eMember css file didn’t specify !important on all those settings?

That way, we could override only the settings that need changing in our child theme’s style sheet and not have to worry about future upgrades changing the files back again.

[jkd]

That’s fantastic, guys!

One last comment/note…. I would suggest that if multiple free memberships are offered on your site, then certain precautions should be taken when creating the pages for registering. When the user verifies their email address by clicking on the link in the email message, it takes them to the page that is defined in the Pages/Forms Settings -> Registration Page (Mandatory) field. So if the page defined there has specifically been designed for one particular free membership, the user could get confused when completing their registration process if the membership they originally sought isn’t what that page portrays. (The registration process will work fine, just may be a bit confusing for the user reading the page, if you catch my drift.)

So, here’s what I did… I simply prepared a separate page, entitled “Please Complete Your Registration” and entered that page URL in the above settings. This page doesn’t say anything specific about any particular membership. It basically just calls [wp_eMember_registration]. The eMember software knows the membership level already so there’s no need to do anything else. And I make sure that this page isn’t referenced by any other page in my site. I only link to specific registration pages that I created for the purpose of registering for particular membership levels.

Cheers!

[jkd]

Hi..

I ended up modifying a couple functions in the eMember suite with a few lines of code.

function free_rego_with_email_confirmation_handler($atts=NULL)

-Added the $atts parameter and shortcode_atts to get membership level.

-Added an optional hidden form field to post with the form

function emember_process_free_rego_with_confirm_form()

-Added the check to use the hidden form field if it exists

Now I can simply enter the shortcode [free_rego_with_email_confirmation level=3], which now accepts a parameter specifying the particular free membership level that is being processed.

It’s completely backward compatible and doesn’t break any existing functionality. If I submit the code, will you include it in the next release so I don’t have to worry about future releases?

[jkd]

Even with method 2 of forcing an email verification, described here:

http://www.tipsandtricks-hq.com/wordpress-membership/free-members-must-confirm-their-email-address-460

When the user get’s back to the site to complete the registration process, the free registration level that is indicated in the settings page is always the free level they’ll get. I’m hoping there’s some way to override that setting and make sure the user gets the registration level they originally wanted.

[jkd]

This seems to break the “User must verify email address” option, however. Is there a way to make sure all free membership levels force the user to verify their email address?

[jkd]

Thanks for those links. From those conversations, it seems this isn’t something eMember/eStore will support out of the box.

If someone logs on with user/password to [www.mydomainA.com] successfully, and then they click a link that takes them to my other site at [www.mydomanB.com], they would have to log in again because they’re two separate databases. (right?)

It would be a nice feature if these plugins allow a master/slave situation, where the slave installation would simply point back to the master’s user & store db.

The other conversation mentioned that it probably could be done by updating some of the php files to reconfigure the pointer to the db. I realize this is outside of the support for the product, but could you give me a hint as to what else might have to be tweaked? For example, are cookies involved here? I mean, how does the server know that the particular browser is signed in? If cookies are used, then they’re probably based on the domain name. Just trying to get an idea of how much work it’s gonna be for me to program this myself.

[Author]

Posts