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

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


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

I’m using 2.5.5 and 1.09 and I’m also experiencing this problem with the return parameter. When I check the rendered form markup I can see this in the HiddenFields div: <input type="hidden" name="RET" value="http://domain.com/templategroup/template"> Whereas that value is just the path to the template where I’m using the profile:edit:login tag. and ...


3

I think you'll need to just use a Safecracker form to create a regular old member account, and then on the backend use the Profile:Edit utility under the P:E Settings to associate that new member account with the existing P:E entry. If you need this all to happen from the front-end, I'd dig into the P:E utility to see how it works and maybe reuse that code.


3

SUCCESS!!!!!! Admin > Security and Privacy > Security and Sessions > Allow members to change username was set to NO! Changed it to yes and voila! Erghh. Simple fix but should be documented somewhere! Hope this helps someone out there!


2

In EE 2.6.1, the reset password routine works differently compared to pre-2.6 version. Instead of being sent a password reset link, followed by a generated new password by email, users receive a link by email to visit a page on EE to reset their password themselves. As of this writing, this new password reset method isn't available in User yet, but we're ...


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

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

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

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


1

You may be able to use something like Stand-Alone Member Registration to create the new profiles from the front-end but I'm not sure how in sync you need those to be with your existing Profile:Edit channel entries? That will create the member entries at least.


1

You'd want to use the cartthrob_pre_process hook. Your extension would look something like this: public function cartthrob_pre_process() { if ($this->EE->input->post('create_user') === 'yes') { $this->EE->config->set_item('req_mbr_activation', 'none'); } }


1

From looking at your code, you aren't telling Profile:Edit what member group to place the new user, so it's using the default. Based on the Profile:Edit documentation your code should include an admin visible ONLY: member group drop down menu. {if logged_in} {exp:profile:register} {exp:profile:member_group_select member_groups="5|6|7"} {/...


1

As Jessica noted, "Require Member Account Activation?" is an EE config setting (available in the CP Member module) that Profile:Edit is simply echoing in its own settings. Unless you change this setting to "No Activation Required" then the new registered user will go into Pending group if you are registering them with a Profile:Edit register tag. To get ...


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