I recently performed some maintenance on a site where users could enter HTML+JS code via a CMS. Examples of such code would be leads/conversion tracking, page views, retargeting, livechat, etc. In the case of this site, the CMS inputs provided for entering the code were TEXT inputs! As one might think, this design decision proved to be terrible UI/UX.
Issues that resulted from this design:
- No formatting is supported. You cannot have line breaks, or for that matter tabs to indent lines of code for readability.
- Pasting code into the text input would strip all line breaks from the code. This can break the code in certain instances, such as when a comment is present. Any code appearing after the comment token is ignored!
- Most end-users do not know much about HTML or JS. They have no idea if the code they’re pasting is valid. Sometimes as code passes through various mediums like email, issue tracking systems (e.g. Jira), or copying directly from a webpage, certain characters can be substituted. Sometimes placeholders or other notational text is present as well. The users have no indication this is bad code and paste it as-is. The error I saw most often was single quotes replaced by the HTML entity '
The situation was bad. My first thought was to change the input to a textarea. This is a step in the right direction because you at least get line breaks back. But what about if you want to indent/tab some lines to keep the code pretty? It can’t be done with the default textarea control because tab takes you to the next form control.
I decided the best thing to do would be to convert these fields into embedded code editors. With an embedded code editor, you get all the benefits of an IDE; tabbing, bracket pairing/highlighting, syntax flags, etc. This would be the solution that would most beneficially impact the client and their users.
I started by googling around and after a few minutes of investigation found that the defacto embedded code editor seemed to be Ace.
The documentation on the site is pretty good, but it only showed the most basic setup which was a JS editor. With tracking code, it is almost always a combo of HTML + JS, because they usually have a pixel they fall back on when JS is disabled. e.g.:
<noscript><img src="//remote-site.com/1x1.gif" /></noscript>
Therefore, I could not just use the JS mode alone, I had to use JS + HTML. One other requirement was having multiple editors active on the same page, one for each field (think header, footer, conversion code, etc.). After A LOT of research, I was able to compile together a solution.
First, I created the form fields on the main page, setting an attribute to flag them for conversion as embedded editors:
<textarea id="frm-header-script" name="frm[header_script]" data-editor="1"></textarea> <textarea id="frm-footer-script" name="frm[footer_script]" data-editor="1"></textarea>
Then I created a separate ace-engine.js file that would contain the code for configuring, initializing, and running the editors. Read the comments in the code for an explanation of what’s going on.
Once you have that, include all ace library files, along with the ‘engine.js’ above that ties them all together:
Note that I had to download jshint.js separately. I also had to use an earlier version (v0.9.1), to resolve a jsnode event emitter error.
Ace it very cool and virtually plug ‘n play. But advanced configurations can be a bit cumbersome. Hopefully this article provided a quick primer in setting up an advanced configuration!