0 users online. Create an account or sign in to join them.Users

Search

I see your point, @gunglien. I had setup a "revert to old address" event in case of mistakes (deactivated members are allowed to log in) but indeed, it's getting redundant.

Moreover, for some reason the Default Event Values does not work on the event that allows the member to update their profile (no value is passed for the email) but I can't seem to find a pattern for a bug or error.

In any case, it looks like I will need custom events for this and PHP coding is way beyond my skills. If anyone is willing to assist me for a fee I'd be grateful!

@ellie I'd be more then happy to help out if needed. I'll drop you an email shortly.

@ellie, I thought about it.

There is no simple way to achieve what you want. You would need to get your hands dirty with custom Members events.

Regarding your desired workflow, I wonder if deactivation (of a Member) might have a siginficant disadvantage. Wouldn't the Member get the default role again after re-activation? So what if you have several roles, and you have already assigned a different role to that Member? Will this assignement get lost? Maybe you can tell us, because you already tried. :-)

Anyway, the added security is an illusion. No matter what you try, you can never guarantee that Member email addresses are valid (and "trackable"). The best you can get is: An address has been valid at a certain point in time. But that doesn't help a lot, because there are special services on the internet offering disposable (short living) email addresses for people who want to register "anonymously". Such an address is by no means better than a complete fake. All in all, you can not prevent that Members give you "wrong" email addresses.

There is one small advantage of your workflow: You would be able to prevent typos in email addresses if any change to an address requires email validation. But that is only a small advantage, so I am not sure if it's worth it.

Thanks, Michael! I took the liberty of continuing the discussion in the Members' thread.

Create an account or sign in to comment.

Symphony • Open Source XSLT CMS

Server Requirements

  • PHP 5.3-5.6 or 7.0-7.3
  • PHP's LibXML module, with the XSLT extension enabled (--with-xsl)
  • MySQL 5.5 or above
  • An Apache or Litespeed webserver
  • Apache's mod_rewrite module or equivalent

Compatible Hosts

Sign in

Login details