4

We have text fields and areas displayed within our Exact Target Landing Pages which had been inserted into a Data Extension text field using AMPscript enabled landing pages. We are using the "pre" tag to hold minimal formatting but it appears that special characters and html Markups won't display as intended. I see no way to apply bold to a word, create a Bullet list or display special characters such as a (c) copyright indicia, umlauts, tilde's etc. I poked around here and haven't seen anyone address this on SO or SE. This is a pretty solid requirement for this internationally reviewed set of pages and something I'm pretty confident will have a simple solution.
We are using "upsertdata" to post the variables and update the text field in the extension from the text area on our form. I also see that if anything is entered with "inch marks" that it does cause errors on the upsertData either duplicating or changing content.
SO //(-_-)\ - Turns out in experimenting that the HTML markup WORKS as well as special characters. I feel pretty certain it had not in the past but it does(?!?) Going back to edit the text breaks it so still not perfect but this changes the question.
I think what I'll really need is to implement a CKeditor style text editor for that text field.

  • Do you have any examples of what you are storing, and how it's being rendered? – Kelly J Andrews Jan 16 '14 at 14:31
  • 1
    pages.info.bentley.com/event-details-ae/… That item shows an example of some strange behavior. The UL's which I thought were not displaying before are creating a bullet list now, but in entering that code in the field it somehow added the "title" tag applied in the Admin landing page into the data extension text field. Strange!? The "0149" was an attempt to display a special character (I think a copyright indicia) - the admin page is secured, you need to log into our account to review it. – Jonny Shaw Jan 16 '14 at 14:39
  • 3
    Can you post the html that is being entered into the text fields? Also, might need to see how you are inserting into the data extension. I need to see more code here to help out. Just edit your post and add the item in there. – Kelly J Andrews Jan 16 '14 at 14:49
  • 1
    !!Update!! - I think Moving the title tag before the Text Area Value field (the variable) in the field details should prevent an extra set of quotes from confusing the title tag's quotes with the text fields. Still some anomolies and can't yet see how to post foreign and special characters within this area. – Jonny Shaw Jan 16 '14 at 14:51
  • 2
    I'm feeling foolish as I went in and tested the same document and while it's somewhat imperfect I am now using the foreign character codes and basic HTML and it's working fine. Not sure why I thought it had not been. That said, it changes the characters if we use the AMPscript powered form to re-edit the item. I know this changes the question itself so I will update the original post to clarify. – Jonny Shaw Jan 16 '14 at 16:08
3

Are you adding them via .csv? If the encoding of the file that is storing the information is Unicode (or whatever encoding is needed) the Data Extension should accept it correctly since you said they are set to a field type of 'text.'

  • 1
    Welcome to the fray, Rob :) – Kelly J Andrews Jan 16 '14 at 15:16
  • 1
    Rob, we have an AMPscript powered form on ExactTarget which is used to add and edit the event lists and details. The form field here is a simple text area and the data extension field is "text". – Jonny Shaw Jan 16 '14 at 16:10
3

Due to ease of use and implementation, I would suggest using TinyMCE as an editor for landing pages in ExactTarget.

You can upload the js file to ExactTarget's portfolio, and call it on your page like this:

<!-- Place inside the <head> of your HTML -->
<script type="text/javascript" src="<your installation path>/tinymce/tinymce.min.js"></script>
<script type="text/javascript">
tinymce.init({
    selector: "textarea"
 });
</script>

<!-- Place this in the body of the page content -->
<form method="post">
    <textarea></textarea>
</form>
  • 1
    That sounds awesome. I don't think I'll have a chance to implement it today but will report back when it's in place and working. Da Boss should be real happy when it's in place. Appears t here are two versions, a standalone and jquery. I'm guessing since the pages already feature jquery that version may be lighter as a result. – Jonny Shaw Jan 16 '14 at 20:25
  • 2
    Great! Also - be sure to mark questions as answered, so people know that they have been correctly solved when they are looking at them. Thanks! – Kelly J Andrews Jan 16 '14 at 22:25
  • 1
    I added a self-answer to summarize this since it was an assisted self-discovery (and error in the initial question). Looking for a place to mark the question as "answered".- am I missing a button somewhere? – Jonny Shaw Jan 21 '14 at 0:38
  • 1
    I downloaded tinymce and noticed it has several sub-directories and paths. This can be an issue using the portfolio as everything must reside at the same level. Are you suggesting that all I need is the main .js file and the rest will default OK without the "plug-ins"? – Jonny Shaw Jan 31 '14 at 18:49
  • 1
    Not really sure - any TinyMCE questions you have probably can be answered over here. You should be able to get it all to work in ET in some form. You may also host those files on another server if required. – Kelly J Andrews Jan 31 '14 at 19:19
3

Update: A KEY factor in handling various languages and character maps in ExactTarget landing pages is to be certain that in the pages "Properties" settings you select "Unicode UTF-8" as the character set. If this is not set the system will only render whatever characters are included in the selected set (ie. "United States - US-Ascii"). Applying this setting to our pages seems to be working perfectly to have all text render correctly in the language and alphabet intended (English, Spanish, Japanese, Russian, Chinese, Korean, etc.)...

I'm answering this myself simply to make sure a summary of the solution is connected to the post. Essentially the system was able to interpret the basic html markup without problems but somehow I thought I had seen evidence otherwise. So yes, between the text area and AMPscript, the Data extension etc. when tested, HTML markup worked fine, though re-editing the fields cause quirky behaviors (needs to be re-entered again as HTML if the item is edited). I plan to implement the test editor Kelly posted above and may comment back to verify how well it works.

  • 1
    In the long run, if you are planning to do a lot of HTML edits, I would suggest you go with a wysiwig editor. It will produce better, consistent results. Glad it's working! – Kelly J Andrews Jan 21 '14 at 1:27

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.