aMember ... what were you guys SMOKING?

I've never wrote a rant like this EVER in my life ... it's my first. So just IMAGINE how frustrated am I to ask you...

"aMember, what were you guys smoking when decided to go ahead with this update?!"

We've been using aMember for years now (that is amember 3.x) and were delighted by its features and that it was a perfect set-it-and-forget-it system.

Yeah the internal code was weird, took some time to understand in order to bend it to your needs, and choosing Smarty for templates was a questionable choice. You couldn't easily split-test a lot of stuff. And you had to custom code your way through, but at least it had all the basics right.

And I was quite happy!

So being satisfied customers of aMember 3.x we decided to go ahead and upgrade to 4.

After all, the newer is always better, right? iPhone 5 is better than iPhone 4s, which was better than iPhone 4, and so on. So how one can go wrong with this update which took you YEARS to release?

Well... Let me tell you how...

It seems like today our coders spend more time trying to recreate basic features that were given as basic ones on aMember 3.

For one, only unique emails on signup page? I don't know if anyone of you track your buyers' behavior, but in our niche people tend to register a few times before buying. In fact, 37% of them do that.

So what happens here is one of three: Either your leads leave without ever coming back, they contact your support asking, "What the heck?!", or they get new email (Yeah, right...) I myself enter my email at least few times into signup form before making a buying decision.

Being FORCED to use only unique emails on signup form means reducing our revenue by 37% - that's more than a half-million a year lost. Not cool.

Now this might be only in some businesses. Maybe your biz is different. I don't know. But at least it would be nice to have an option to turn off "Unique Emails ONLY!" function ... like you had in aMember 3.x (Hello?)

Thanks God, aMember DOES have a GREAT support! You guys rock at that. Simply by sending a hack to the issue, you save tons of time. But then again, why does it have to be hacked in the first place?..

Then there's this "One Global Signup Email Template For All Products" issue...

UPDATE: Yes, so much for my "smarts"... Just got an email from aMember:

Here it is:
aMember CP -> Protect Content -> E-Mail Messages: New Autoresponder​

We have 21 different products all served nicely by our aMember 3.x installation. Every one of them has a custom email welcoming and thanking clients for their investment. But now you can only have ONE?

Common! ... You had it right before, why change it?

People who have one product - leave em option to have one global email. People who have more products - why constrict their freedom?

So now we're hacking this issue, too...

But then there's this "super secretive" thing with passwords.

I think it's logical to send your customers' passwords in their welcoming email. Most of the time they forget those, so it's good to have it as a reminder. Unless, of course, you're a bank or dealing with some sensitive information.

But my guess aMember as a company is dealing with your standard Information Marketers. We don't have that many things to hide, common!

So why make such a big deal about those passwords?

For the love of God, I used to have a "Member's Page" that didn't even have secured areas. We used dummy text fields with an image link below it saying, "Login". You could put ANYTHING into those fields and still be given access. And it worked great for that time.

Basically, what I'm trying to tell you is that we used to have a Welcome email that said WHERE to login and WHAT to enter into login fields (in other words, their username and PASSWORD!)

Now, you can't send passwords anymore?! WHY? Can't this be a simple option too, for people who deal with sensitive information?

For me - give me an option to send them their password by mail in their welcoming email. That saves me and our support team a ton of time.

...I wouldn't be surprised if aMember 5.x had a physical "code generator" ... you know ... like the ones you get in banks to log in to your bank account.

So basically what we'll have to do now is generate one password for all of them, just to be able to send it by email. Yup, smart!

And what's about removing {$payment.receipt_id} tags and {$payment.begin_date|date_format:$config.date_format} tags which you had in aMember 3.x from email templates too?!

THOSE SAVED A LOT OF TIME WHEN LOOKING FOR A TRANSACTION WHEN YOU HAD TO REFUND OR CANCEL SUBSCRIPTION. Why?

To sum all things up, our team is now spending major portion of their time to HACK our way through to make aMember 4.x look and feel more like aMember 3.x and the lack of documentation doesn't help either.

The sad thing is that we have a very close launch deadline that leaves us not enough time to downgrade and go back to aMember 3.x

...and I can only imagine what will happen to our "hacks" when and IF we decide to update to the newer 4.x version when there's one...

So yeah guys, you ROCK at providing world-class support ... but this update ... you went ham with it in the wrong direction...

Now... I might be missing, and maybe there IS a way to turn these options back on. But look, I like to think of myself as an advanced user ... AND I CAN'T FIND WHERE THESE ARE. So yeah...

Yes, so much for my "smarts"... Just got an email from aMember:

So maybe I AM missing something here?

#3) sure, that's all nice and dandy, but you can't set up autoresponders to include a PASSWORD field anymore in those emails, nor can you include a PRODUCT NAME field in there now either... so if someone was to disable the global registration email (under #2) and set up unique welcome emails as autoresponders instead, they would never be able to send passwords to their users nor let them know what product they signed up just a minute ago (speaking of customized autoresponders).

And I like that suggestion above - why force aMember 4 to use hashed passwords only? Why not have it as an option in Setup/Config somewhere to enable/disable that, or to switch from plain text to hashed passwords instead?

It doesn't matter what other "modern products" are doing and how they are storing their passwords... what matters is how YOUR users and potential clients want to have those passwords stored and how they want to have access to them

Alex, again, you are trying to anticipate people's problems and solve them for them... even though they might not consider it a problem.

What I'm saying is give your clients a choice of how they store passwords and leave it up to them to deal with it the way they'd want to... you making the decision for them is kind of a problem

Miso, I have to disagree with you on the password issue. You cannot be safe enough when it comes to storing passwords. Maybe security is not a priority in your line of business but in our business we have to be as secure as possible because we are dealing with various services (payment processing, DRM video content, etc.) that we need to have most (99%?) of the bases covered. I would highly suggest against storing passwords as plain-text.

see, now you are not hearing what I am saying either - leave it to individual customer to decide whether he wants to turn that on or off in his installation.

you, you'd probably turn it on because it's important to you.

some of my other clients, who are now complaining about not having access to plain passwords in their autoresponders and emails to send out to users, they'd probably turn it off, as they survived just fine on v3 with plain text passwords and it's not such a big deal to them.

The password thing is no big deal - where I used to insert the password for them, I now say something like this:

Gotta say I love the new version of Amember

Just gotta chime in - I was an aMember v3 user for 8 years and just recently upgraded to aMember v4.

The passwords being stored in plaintext in v3 was a HUGE database faux pas. So big in fact, that I modified the user profile forms to replace the password with asterisks as it should've in the first place. If you have multiple admins, you certainly can't trust every single one of them to not be tempted to do something sinister with visible security info.

I don't know what business you're in miso, but a user database with plaintext passwords is a legacy idea that the entire world just needs to move on from. While I would usually hands down vote in the "let the users decide" camp, when it comes to security, I irrevocably disagree.

Let's say aMember let you choose to store passwords in plaintext and then your database is compromised/hacked/etc. When that information comes out, it will also come out that this hacked database was brought to you by aMember - instant bad and irreversible publicity. It doesn't matter that you as an admin chose plaintext and you had an encrypted option; the only details that will matter to the general public is that a user database got into the wild, passwords were plaintext, and aMember was the software that managed the database.

aMember did the right thing encrypting passwords, ESPECIALLY in a system where monetary transactions are involved. If this were some casual forum database with no money involved, maybe plaintext passwords might be ok - but this is a money-driven subscription suite. The passwords NEED to be encrypted and the world's end-users just need to get used to that because it's for their own good.

^^ that's the thing - some people use aMember for just unifying a few pieces of software like wordpress, forum, etc without charging any money. But whatever, we've all got our opinions.

anyway, what would be a happy medium would be a standalone "reset password" page that could be embedded into emails and autoresponders with user's username prefilled in the form, so all they have to do is press "reset my password" on the page they land on - minimize the steps required to reset their password, in case they forget it.

After years of using amember3, we just upgraded to amember4 and I'm having trouble with the new password storage approach too.

Since we use the "shopping cart" (we use both UltraCart and Clickbank), in front of amember, the passwords are randomly generated, not created by the user, it's very helpful if we can access the passwords to make customer support much easier.

It would be really appreciated if you could make cleartext passwords an "advanced" option.

As a further refinement, you could make this available ONLY for randomly generated passwords. If the customer creates their own password, I do agree that it should be encrypted. They tend to remember those.

Thank you