4

We're transitioning all our old email code from the Classic Content into the Content Builder, but I've run into an issue several times that looks like a glitch in the HTML editor (NOT the wysiwyg) to me when writing AmpScript. When using the 'less than' operator < in a comparison, the html editor is interpreting that as an HTML tag opening like you'd see in <table>. as a result when I save my HTML block the editor goes through and edits my code assuming that I've screwed up an HTML tag and keeps my intended ampscript from functioning.

My code is this: elseif ROWCOUNT(@rs_email) < 1 then

I'm checking whether a data extension has results for my intended audience. My workaround currently is switching the order of the comparison, since the "greater than" operator isn't misinterpreted.

Workaround code: elseif 1 > ROWCOUNT(@rs_email) then

It's annoying and I'm wondering if this is a known issue for anyone else, or if I'm doing something wrong.

Here's a screenshot: raiseerror code

The code highlighting is indicating that it's trying to read this portion as HTML. It's in an HTML block, but that's how we've always done our AmpScript before, not sure why it would change in Content Builder.

6
  • Not had this issue but top points for finding a work around must have been very painful! I would suggest framing it as. A question and posting the answer. Definitely a strong learning point and might save some poor other person the misery
    – 0xsegfault
    Commented Jul 27, 2017 at 13:31
  • Now I'm looking at the code I just screenshotted, and just now realized that the elseif is redundant and should just be an else statement... SMH. The problem is still there, so I'll leave it up to see if anyone else has any insights. Commented Aug 1, 2017 at 12:49
  • 1
    @KevinIllick I'm a little confused by the description. Are you saying it's changing your AMPscript or at you just bothered by the color coding?
    – Don Owens
    Commented Aug 17, 2017 at 13:30
  • @Don there was one time where it actually stripped out part of my Ampscript, I had assumed due to the color coding it was because it wasn't valid HTML. I didn't keep a record of what I did that specific time. This specific example was a coloring error, and if I wasn't careful with the rest of the code in the section, the editor wanted to autocomplete the non-existent tag. Commented Aug 18, 2017 at 13:53
  • @DonOwens, is there any chance of creating an 'Ampscript' block type, that's guaranteed not to affect any coding or characters? Essentially removing any "autocorrecting" or formatting applied to HTML blocks currently? this problem has gotten worse with the most recent release. link Commented Jan 31, 2018 at 13:03

1 Answer 1

3

EDIT: Thanks to your screenshot I now reproduced the issue and have a workaround for this that might be easier to put into action as you are possibly migrating a lot of emails and changing every operator is quite painful then.

The workaround is similar to Adam Spriggs approach (see original answer below) to solve the messed up preview, which my workaround also does, but uses html-comments instead and therefore also fixes the misinterpreted operator:

%%[
  /*<!--*/ 
    Var @count, @output
    Set @count = 2

    IF @count > 0 THEN
        Set @output = "greater than 0"
    ELSEIF @count < 1 THEN
        Set @output = "less than 1"
    ENDIF
  /*-->*/
]%%

<p>%%=V(@output)=%%</p>

Original answer:

Usually there is no problem when using HTML content blocks or HTML emails. However AMPscript in other types of content blocks doesn't work properly.

When using the opening %%[ and closing ]%% tags I never had problems with misinterpreted operators.

Only preview is pretty messed up, but Adam Spriggs proposed a workaround for this which is extraordinarily helpful:

%%[/* Modify to view AMPScript <div style="display:none"> */
/* your big blob of AMPScript goes here */
/*</div>*/
]%%
7
  • I'm using an HTML block (screenshot above). I've definitely used Adam's workaround for other sections of code, it's super helpful when trying to clean up the outward appearance of the code, this is more about making sure the code functions as ampscript though. Thanks! Commented Aug 1, 2017 at 12:47
  • Ok now I got the complete problem and updated my answer with a workaround which doesn't require that much changes as you only need two little adaptions per AMPscript block rather than changing every operator. Commented Aug 1, 2017 at 13:38
  • This works, I'll mark it as a correct answer, I'm still thinking about raising the issue with Salesforce to see if they know about it though. Thanks! Commented Aug 1, 2017 at 14:21
  • @KevinIllick - any luck with Salesforce on this? It's still a problem. :(
    – Daniel
    Commented Jan 30, 2018 at 5:14
  • @Daniel No, unfortunately. There's a ticket open for this (I lost track of the ticket number), but their most recent release on Monday exacerbated the situation. The workaround is to put anything you don't want them to touch in a "snippet" instead of a content area. The problem with that is with the new release you can no longer drag and drop snippets without an HTML block, so I haven't found a workaround. We're switching to HTML paste emails, as those are not modified with whatever ASCII autocorrect they're doing. Sorry I don't have more! Commented Jan 31, 2018 at 12:43

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .