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.

  • 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 – Samuel Dare Jul 27 '17 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. – Kevin Illick Aug 1 '17 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 Aug 17 '17 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. – Kevin Illick Aug 18 '17 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 – Kevin Illick Jan 31 '18 at 13:03
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>*/
]%%
  • 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! – Kevin Illick Aug 1 '17 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. – Markus Slabina Aug 1 '17 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! – Kevin Illick Aug 1 '17 at 14:21
  • @KevinIllick - any luck with Salesforce on this? It's still a problem. :( – Daniel Jan 30 '18 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! – Kevin Illick Jan 31 '18 at 12:43

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.