4

I had the same issue, and ultimately discovered it was caused by a setting in Focus Labs EE Master Config. In config.master.php around line 258 you'll find: /** * Member-based settings */ //$env_config['profile_trigger'] = rand(0,time()); // randomize the member profile trigger word because we'll never need it I'm not sure why randomising the ...


3

You can definitely do this. General setup would be something like this. Set Require Member Account Activation? to No activation required Create a custom member field to indicate whether member has completed the email activation process. Email confirmed? : y For the pages (or specific elements) of the content you don't want them to access, run a check for ...


3

LogMeIn add-on has not only option to login user, but also logout. Just add next tag in your template {exp:logmein:logout}


2

Whilst I'm keen not to see this site become a 'do-my-homework-for-me' -type thing, I quite fancied having a go at this and had both some spare time and magnanimity... so please try out Perfect. It's very basic at the moment, but let me know via the Devot:ee forum of any extra features you need to make it useful.


2

First things first... I would recommend that you don't do this at all and instead find a way of using the real email field for whatever purposes you need it. Mainly because the pain of having to keep dual fields in sync will become very tedious, especially if members can update their own email address. However, if you insist on doing this there are two ways ...


2

It seems that you're missing the variables within the tag to output the errors. See the errors portion of the docs for information about the available variables and conditionals.


2

Here's how we did this type of thing. The site uses the following checkout sequence, but using EE custom member fields and freemember rather than Profile Edit. View Basket > Add customer details > Checkout confirm > Payment Gateway > Confirmation - with option to register We've setup the member fields, giving them the same short names as the customer ...


2

I can't offer a specific fix, but I would make sure you have the most recent version of EE, CartThrob and Profile:Edit installed to eliminate bugs in the code.


2

The simple answer would be to go through the add-on code and replace any ampersands with html entities but I'm guessing you've already tried that? I don't think there will be a quick way to do it other than doing that. I would say that you really don't need to worry about it. Validation is a guide, not a requirement. Especially at this level. Are you ...


1

There are a number of add-ons available that will allow a notification email to be sent upon creation of an entry, which is what Profile:Edit does. Check out Postmaster


1

No, it is not - Mighty Big Robot is not developing, selling, or supporting any of their add-ons anymore. Maybe have a look at Zoo Visitor.


1

Are you trying to display them, or edit/save them? To display them you can just show the fields not as inputs?


1

It actually sounds like it has to do with MySQL TEXT versus LONGTEXT. Try changing the type for your WYGWAM fields and see if that corrects it.


1

OK, so thanks to Chris from Mighty Big Robot for his support call this morning, we tracked this back to the Terms of Service text area field being called rules: <textarea name="rules" style="width:98%; margin-bottom: 1.5em;" class="textarea" rows="9" cols="90" readonly="readonly"> He changed this to the_rules and it fixed the initial problem: <...


1

Another option, if this is a big security issue, is to build an extension that hooks into either Profile:Edit or the underlying Channel Form and validates the POST array before it is processed any further. Take a look at the extension hooks available in Profile Edit and/or Channel Form and you find one that is called before the profile is updated. You can ...


1

I'm not certain this is something you have to worry about, unless you are also somehow providing your database schema to the user as well. Generally speaking in EE a name field is rarely just called a name field, it might be called profile-name or profile_name. So if you had custom fields that you aren't displaying, then no one but you or other staff members ...


1

I had a similar issue (EE 2.8.1) and solved this by modifying the logout link to: <a href="{path='?ACT=109'}&XID={XID_HASH}" role="button">logout</a> You'll find the correct action_ID (ACT) for the profile:edit logout, in the exp_actions table.


1

To sum up the fix: Open P:E's config.php file. Change the file number from 1.1.8 to 1.1.81. Go to EE > addons > modules > run module updates That should fix the whole thing. The root of the problem is that EE changed their extension hooks from safecracker to channel form from 2.5 to 2.7. P:E's set to change the hook, but it looks like it had been updated ...


1

I've been working on a EE 2.7.0 site that uses the latest Profile:edit and has this password reset form, and I've never seen the issue you're describing. If this were happening on just one page, I'd say that it sounds like maybe you have EE access restrictions set on your Reset Password page, with the restriction's "unauthorized" redirect pointing to the ...


1

The key for the avatar to be removed is to submit form data for "remove_photo". This means that you need an HTML form field for this to work. Hyperlinks are not form fields. You can, however, trigger the form submission with a value "remove_photo" by using javascript/jQuery. The "remove_photo" field can be a hidden field as well. For example, if you had: {...


1

I've noticed this too: Profile:Edit does prevent duplicate member email addresses and usernames, which is needs too. But, not screen names. Note that Rob from Mighty Big Robot commented on this issue, before, on this site: How to keep Screen Name in sync with Profile channel fields using Profile:Edit


Only top voted, non community-wiki answers of a minimum length are eligible