2

I've just discovered that for some channel fields (from investigations so far, those that are marked for markdown formatting) {encode email="you@example.com" 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.

  • Since no one has asked - what version of EE is this happening on? – Derek Hogue Jan 15 '13 at 13:19
  • 2.5.3 from what I could see, the part affecting this hasn't changed much, but I could very well be wrong. – UltraBob Jan 15 '13 at 22:10
1
+100

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="you@example.com" 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.

| improve this answer | |
  • I will go double-check on this when I'm not laid up sick, but it sounds likely to be it. I think I had heard about 2.5.4 being incredibly buggy and hasn't bothered to look at 2.5.5 yet. I'll do that and if it fixes I'll be delighted to aware the bounty. – UltraBob Jan 17 '13 at 23:24
  • Oh yeah, and the code being wrong is just a brain fart when typing the question that somehow escaped all later edits. In my actual code I do this correctly. – UltraBob Jan 17 '13 at 23:25
  • I wish I could have a little bit more time to review and make sure this is actually going to do it, I'm not going to be able to upgrade EE today and the bounty expires sooner than I'll get to it. That said this seems like it is likely to be the right answer. I'll award the bounty here, and come back and accept the answer as well if the upgrade turns out to fix the issue. – UltraBob Jan 21 '13 at 8:32
  • After installing the update I can confirm that the problem doesn't exist even without my core hack, and furthermore it appears that Ellislab has rolled in all the security patches they had given me so I don't have to worry about managing an install with hacks to core anymore. Oh happy day! – UltraBob Jan 22 '13 at 9:27
2

One solution I found is to use [email="you@example.com"]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.

| improve this answer | |
  • {encode} does work, but apparently not in WYSIWYG fields, which convert the {} curly brackets, but don't convert [] regular brackets. I had to deal with this on a couple of sites, after adding WYSIWYG fields. My solution was the same as yours, see: ellislab.com/forums/viewthread/231090 You can use the FIND and REPLACE command fairly easily, though it may require multiple passes. Also, I think some WYSIWYG field_types have their own encode email option, so depending on which one your using, that maybe a future option. – nonprofit_tech Jan 7 '13 at 8:34
  • Not a WYSIWYG field, it is a normal text input set to formatting markdown. – UltraBob Jan 7 '13 at 12:24
1

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?

Standard Format Options

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:

Markdown Field Example Image

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}.

| improve this answer | |
  • huh, it turns out that even when I'm in xhtml, auto <br />, or none mode those encode tags are not working. I had forgotten, but the markdown plugin I'm using is one I had in EE1 that I updated myself. I turns out that seems to not be my fault though. I guess my next step is to take a hard look at my config and see if I'm somehow doing this to myself. – UltraBob Jan 10 '13 at 7:15
  • /me glares suspiciously at the text here – UltraBob Jan 10 '13 at 7:59
  • by the way, I really appreciate the in depth answer. I guess I should have done more in depth poking around before asking the question, now the question has changed a little. I'll go update it. – UltraBob Jan 10 '13 at 8:11
  • If they aren't working in any of those modes, then it sounds like a configuration issue. Is your suspicious glare at encode_removed_text appropriate? Did that help? – nonprofit_tech Jan 10 '13 at 8:12
  • I didn't have that setting anywhere, that test just made me suspicious that there must be somewhere to disable email encoding. I sure couldn't find it though. – UltraBob Jan 10 '13 at 8:15
1

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.

| improve this answer | |
0

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.

| improve this answer | |
-2

(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

| improve this answer | |
  • Fair points, with which I agree, but not an answer to the OP's question. – Derek Hogue Jan 15 '13 at 20:23
  • What Derek said. If this was for my address I might not do this, but this is for a group of users' addresses, and requires not even a little bit of effort on their part. Normally it requires less effort on editors' part too. – UltraBob Jan 15 '13 at 21:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.