email encode tag returning the tag as is in channel entries

Question

I've just discovered that for some channel fields (from investigations so far, those that are marked for markdown formatting) {encode email="[email protected]" title="send me an email"} will that tag as is in the output. Obviously the whole point of using encode was not to expose the raw email address, so how can I get the encoding to work again?

UPDATE: Let me clarify that even though I have an answer up here, I'm looking for a better answer, so that is why I haven't marked mine as accepted yet.

UPDATE 2 After some more poking around I've found that I have this issue in any fieldtype and any channel (as far as my testing has roamed) From discussions with others it doesn't seem to be the case that encode doesn't work in general anymore so it must be either something in my configuration, something in my environment, or something in my install.

I have checked through my config bootstrap and my config.php and see nothing that should be causing this, though I'm not aware of an option for disabling the encode tag, so I don't know what I'm looking for.

My server environment has not had any significant changes recently, I don't think this is likely to be it though I won't rule it out 100% if someone has an idea of an environment related cause that I should look into.

My install is potentially the cause. I have some unreleased (session handling related) code from EllisLab that was necessary to address some security concerns raised by a security audit we performed. This had a bug in it before which caused an issue with doing ajax queries in the control panel. I don't think it is likely that there is a bug in that code causing this, but it is possible. Any guidance on where in the EE codebase I should look for the code that should be doing the transform (the typography class?) I'll jump in and debug it.

The end result of this is that I don't have a good guess for what the cause of this issue is, and would like some help in figuring it out.

UPDATE 3 I can confirm that the code that handles email encoding seems to be in the typography class, but I'm having some difficulty figuring out why my {encode} tags are not working. I'll put a bounty on this question to try out the bounty system, and to see if I can get an answer to this. I'll be trying to find the answer first. Feel free to beat me to it.

UPDATE 4 I found a partial answer and have posted it in the answers section of this question. Now I'm looking for an answer about why convert_curly is on in my install and how to turn it off without changing a core file.

Answer 1

If you're using EE 2.5.3, this is a bug. There's a hotfix here if upgrading is too difficult:

{path=} tag resolving correctly in one channel but not in another

Fix and discussion in bug tracker: https://support.ellislab.com/bugs/detail/18239

Also, your syntax is incorrect - it should be {encode="[email protected]" title="Email Me!"}

Edit to add - I read that you found the hotfix manually, however I don't think this was the true fix that made it into the 2.5.4+ version, so comparing that line in the typography file with the new version is misleading.

Answer 2

One solution I found is to use [email="[email protected]"]send me an email[/email] instead of the curly bracket method. It seems like the parser is converting the curly bracket to an entity and then not parsing the tag as expected.

This solution seems like it is going to require some fairly extensive search and replace either using the search and replace tool provided by EE, or writing my own script (or find an addon) to let me do a regular expression search and replace on the database, so it would be better if there was a way to make {encode} work as expected.

Answer 3

Markdown isn't one of the normal formatting options, which add-on are you using to add the functionality? Is it this one?

Can you temporarily revert the field back to 'none', or 'xhtml and see if the {encode} options works then?

The {encode} option should work with the normal field formatting options. But it's good to test anyway. If it works with the normal field formatting, then the issue is the add-on.

Generally speaking, it's the javascript that converts the mark-up. From what I've been able to discern is that most of these field_types or formatting options, all assume that the user will want to occasionally showcase code as part of a post. You can see the issue, in one of the sample images provided by Markdown Field below:

The sample image, shows off Markdown being able to display code. Notice what is part of the code {}. That means the field or formatting type will convert brackets to html entities so that they display. This renders {encode} non-executable, but since normal brackets [] normally aren't converted, they are fine to use.

You can hack your add-on and remove {} from the convert options, or you can use the BBCode option, which is a nice failsafe, built right into ExpressionEngine for these situations ( I don't know if that was why it was included, but I'm glad it works ).

If it's highly unlikely that you will ever need to display any type of code. I say, hack away. If you aren't using the Markdown Field, then I'd start where most WYSIWYG field_types do this, in one or more javascript files in the third party folder of themes for the related item, that contains the code.

If you are using the Markdown Field, then look in the library folder under expression engine/third_party/markdown/ the file markdown.php contains this code at lines 201-203

201    # Table of hash values for escaped characters:
202    var $escape_chars = '\`*_{}[]()>#+-.!';
203    var $escape_chars_re;

That's the starting point for {} references. But you also need to examine the rest of the code, to see if there are other references, and modify them as needed.

I know it's not ideal, but one of the issues of converting plain text and html text to something else, is you get easier formatting, but other things may fall to the wayside. The [email][/email] isn't a bad option, and you can use FIND and REPLACE to handle adjusting any prior {encode}.

Answer 4

So, going in a wildly different direction; the easiest way to fix this is to wrap this in {exp:allow_eecode} plugin-tags, provided by the Allow EECode plugin from EllisLab themselves.

Answer 5

This turns out to be a result of expression engine converting the curly brackets into entities before parsing for encode tags. On line 118 of my system/expressionengine/libraries/EE_Typography.php file I see the following line:

$this->convert_curly        = TRUE;     // Convert Curly Brackets Into Entities

Changing the TRUE to FALSE, resolves the issue. Obviously editing this in core is less than ideal and it actually changes the default behavior for the Typography class.

I downloaded the latest version of expressionengine and checked the value for this variable in the default install and indeed it is set to TRUE, so it isn't a matter of me having somehow inadvertently changed it by accident. I find it strange that no one else seems to be having this issue:

Have people just not noticed that their encode tags are now exposing their email addresses? Am I the only one with encode tags still on their site? Is there an override set somewhere that I need to find?

I welcome comments to this answer to confirm whether the encode tag works for you on your install, and separate answers for how to get it to work again without modifying core.

Answer 6

(from https://superuser.com/a/236152 ) (opiniated bold mine)
There was an interesting article by Cory Doctorow recently on this subject here* which argued that email obfuscation doesn't serve much purpose, and a more optimal approach is intelligently managing the spam you get.

TL;DR version:

• The objective of this entire exercise is not to reduce the amount of spam you get in your email, but the amount of spam you manually have to remove from your inbox.
• Email obfuscation is a constant battle to come up with ever sophisticated bot-proof, human-readable encoding, and is a drain on the productivity of both the creator, and the correspondent.
• "Almost any email address that you use for any length of time eventually becomes widely enough known that you should assume all the spammers have it."
• "The convenience of stable, easily copy-pastable email addresses" wins over trying to hide from the spambots.

* http://www.guardian.co.uk/technology/2010/dec/21/keeping-email-address-secret-spambots