Thread

Yes, that’s very helpful, especially as we had so far not been able to locate that file.  We have all of our channels set to allow all formatting already, and setting the defaults to all didn’t have any effect.  However, we were then able to isolate the issue to the auto_linker function for sure.  Line 673 specifically seems to be one of the culprits (as you might imagine), but so far we haven’t been able to determine why, or if the actual issue might be later on in the process.  I’ll report back if we find anything else.

EDIT: interestingly, it seems that decode_bbcode is nearly unchanged since our last version, but lines 663 and 670-674 appear to be new, so we are concentrating on that.

Ok, here’s what we’ve found.  First, we determined that the BBCode is NOT getting fed to our plugin, so the issue is not with our custom wysiwyg fieldtype.  In fact, it’s starting to look like the only real PROBLEM is with mailto links specifically, with break tags in them, as my bug report claimed.

Right now we believe that the problem may simply be that [email=] is a new thing for decode_bbcode to handle, because lines 670-674 are new.  Is it possible that this type of BBCode is not being handled in as robust a manner as [url=]? We did test by removing the lines in question, and what happened was that the mailto links switched from using [email=] to using [url=] but then the pages are rendering fine.

We think you need to check and see how you’re handling [email=] when you convert the BBCode back to links, cause you’re missing it if there’s a break tag.  [url=] does not have that problem, but mailto links just started being marked as [email=] instead, which is why this is a new issue.

Make sense?

Building on our hypothesis that the [email=] BBCode is now being used in a way that it was not designed to handle, we extrapolated and tested adding ids, classes, and other attributes to well-formed mailto links (without line breaks).  Sure enough, the mailto links are obfuscated just as lines 670-674 intended, but none of the attributes make it out the other end.  This issue basically boils down to a half-implemented improvement to mailto obfuscation (though it’s certainly a welcome one!).  The [email=] processing should be expanded to be robust enough to handle attributes, line breaks in the text, and whatever other things the [url=] processing can handle.

Thanks for the really excellent debugging Dennis.  What I’ve done for now- commented on the bug w/the gist of the issue and confirmed it.  I’m not going to jump on the fix just now unless it’s an emergency as I’ve got a couple of other issues on my plate.

But if it is really jamming you up?  I can work it into my que and escalate getting that one fixed.  Given we want it to behave like urls, I expect most of the code can be extrapolated from that for a quick fix.

So let me know if it is something that needs a fix in asap or if it looks to be a case for bumping the bug severity up (we’ll grab the major bugs faster but not as fast as if you really need me to look at it asap) or if it’s ok as is.

Thanks for confirming this!  We believe that this bug is ok as-is.  Definitely let me know when you get a fix, though, as we can’t upgrade the system very often and we prefer to document bugs and fix them in place if possible.  Thanks!

Sounds good- I bumped it to Major-Low just so it jumps up the list a bit.  We’ll reply to the bug once a fix is in- generally the fix if it’s not too extensive, which I don’t expect this to be.

Since you’re subscribed, should get a notification when we do.  Thanks for all your work on this one- really helped clarify what was going on.