Thread

Using:
Expression Engine 1.6.3 (Commercial License)

Problem:
When using an {email} tag within an {exp:member:custom_profile_data} tag, a long javascript array is shown instead of the e-mail address.  This does not occur in a different template that uses nearly the same code.

Here’s an example of the offending EE code:

{exp:member:custom_profile_data}
<form action="https://someshoppingcartsite.com" class="shopcart" method="post">
        <input type="form" name="price" /><br >

        <input type="hidden" name="customer_email" value="{email}" />
    <input type="hidden" name="name" value="{username} Deposit" /><br >
        <input type="submit" value="Send" />
</form>
{/exp:member:custom_profile_data}

and the resulting HTML output (javascript elements were removed b/c they do not show on the boards:

<input type="hidden" name="customer_email" value="[removed]
//<![CDATA[
var l=new Array();
l[0]='>';l[1]='a';l[2]='/';l[3]='<';l[4]= ...THE ARRAY CONTINUES BUT EDITED FOR BREVITY/SECURITY… l[58]='<';
for (var i = l.length-1; i >= 0; i=i-1){ 
if (l[i].substring(0, 1) == ' ') [removed]("&#"+unescape(l[i].substring(1))+";"); 
else [removed](unescape(l[i]));
}
//]]>
/script" >

Any ideas on how to fix this behavior?

EE automatically encodes the email to reduce the likelihood it will be picked up by spam harvesters.  Note in the docs:

{email}
The user's Javascript encoded email address.

There isn’t really a way to get the unecoded version using that parameter.  Though you can do it with the query mode instead if it’s critical.

Make sense?

Hi Robin, thanks for the quick reply.  I appreciate the explanation for the javascript encoding—that’s a useful bit of knowledge and a nice piece of built-in functionality.

It’s strange though, because when I use the {email} tag in a different template within a hidden <form> input it works fine and passes the value as it should.  The only difference I can think of is that it it is also nested within a an{exp:weblog:entries} tag.

Here’s the example where it is working fine, in a different template:

{exp:weblog:entries weblog="commerce" author_id="CURRENT_USER"}
{exp:member:custom_profile_data}
<form action="https://someshoppingcartsite.com" class="shopcart" method="post">
        <input type="hidden" name="price" value="{price}" /><br >

        <input type="hidden" name="customer_email" value="{email}" />
        <input type="hidden" name="name" value="{title}" /><br >
        <input type="submit" value="Send" />
</form>
{/exp:member:custom_profile_data}
{/exp:weblog:entries}

If it’s some sort of glitch, I suppose I’ll have to use the query method.  I haven’t actually explored how to do queries yet, but I guess it’ll be a good excuse to learn how to use them since they seem very useful.

In the above- you’re nesting the profile tag inside the weblog tag- which may have unintended consequences.  Basically- you’ll run into variable conflicts.  The {email} variable inside the weblog tag is “The author’s raw email address”- so you aren’t actually pulling the email via the custom_profile_data tag- you’re pulling the one from the weblog tag.  It’s basically overriding the custom profile stuff.  Of course- since you’re only pulling entries for the current user- it’s the same thing- it’s just encoded if you pull it via the profile tag by itself.  If it was an entry by a different author, thoough?  You’d be seeing the email for that author, not the current user.  In truth- I don’t think the profile tag is needed at all there.  All the custom fields for an entries author can be shown by the weblog entry tag itself. 

Heh.  Confused more?  Basically- it boils down to the {email} variable for the author’s email inside the weblog entries tag isn’t encoded.  And that’s what you’re seeing in the above.

Aha, so that’s it!  Thank you very much for the explanation.  It makes perfect sense.

I used the custom profile tag because there is information I needed to pull from information the member entered during registration that is not included in the weblog entry.  I didn’t realize you could also show custom member fields just through a weblog:entries tag—that’s a useful tidbit of info!

Many thanks!

😉  Glad it all makes sense!