.png?width=667&height=667&ext=.png)
Revenge of the JavaScript Web Part
Introduction
According to a recent report, JavaScript is used by 93.6% of all websites. To say that's a large amount is a gigantic understatement. Considering the fact that there are over 1 billion websites in the world, that means there has to be at least 100 million different ways JavaScript is used today (it sure feels like it somedays anyway). Even though many developers strive to use the latest patterns, best practices, and modular implementations, the fact is, we all do our client side scripting a little differently. This trend continues into how we use JavaScript in Kentico CMS web development. There are many different ways to handle it in Kentico, and every site seems to have it done just a little bit differently from the next.
There are great articles out there, from some very smart people, on how to best utilize scripts in Kentico. So I'm not going to cover those scenarios in today's blog post. Instead I am going to focus on a real world scenario that I have dubbed "The Revenge of the JavaScript Web part". Basically it boils down to a Kentico quick tip on one very sneaky gotcha, when dealing with the built-in JavaScript Web Part in Kentico. Keep reading to make sure that you are not bit by the same hard learned lesson that my team and I recently went through.
Our Friend - the JavaScript Web Part
Now don't jump to any conclusions and think that I am going to recommend not using this Kentico web part. That is 100% not the case. I totally recommend using it. The web part allows you to re-use scripts easily from the JavaScript files application that lives within the Kentico admin interface. It also has some very nice attributes that give you fine control of when your JavaScript is loaded on the page. Actually I would say that we use this web part all the time.
We frequently use this web part because it allows us to control the sequence of loading scripts on the master page template and standard page template control hierarchy when doing Kentico Portal Engine development. Side note: yes, all you Kentico MVC developers out there aren't going to learn too much from this post, deal with it, I gave you some love in the last Kentico Rocks podcast episode already.
Whenever you add this web part to a page template, and configure it to use a library script, or create your inline script, it will nicely render that script out to your page(s). It's pretty straightforward really.
The Problem
Recently we were working on a site where we added a simple social media sharing plugin to enhance the social aspect of a set of blog post pages. The plugin was powered by an external JavaScript library hosted at the third party service. This is very typical. Now again, you have many options on how to load an external script on a page. Some are better than others, but in this instance we added the external source inside of the inline script attribute of the JavaScript web part. The following screen shot shows a mock-up example.
When we tested out the pages, everything worked great. The social buttons popped up, we tested the sharing out, and even had our custom open graph meta data tags working to pre-populate the title, description, and image properties for Twitter, Facebook, etc. etc.. The code was committed to source control, it passed QA, the client ran through acceptance testing, and the feature went live. People cheered, seas parted... ok that last part didn't really happen.
A short time after we were live, a product critical bugged was logged. Suddenly people couldn't register on the live site. It was a pretty big head scratcher because our change was only adding a simple set of code in a few transformations, and one new web part on the master page template. Since the live site was throwing a server error, we immediately went to the Kentico Event Log application in hopes of finding a lead on what the issue was. Sure enough, it was plain as day as to what the error was. The JavaScript web part had completely thrown us under the bus!
As you can see, the exception generated was not something we were expecting for a client side change, especially since we un-checked the Generate script tags attribute..
Exception: The script tag registered for type 'System.String' and key 'p_lt_ctl00_Javascriptinlinescript' has invalid characters outside of the script tags
The Fix
Luckily it was a simple fix. The only thing we had to do was remove the comment and re-save the page template. After that the social sharing plugin and user registration process worked just fine. Phewww. So really the moral of the story is, don't add full html comments into any in-line script attributes on a JavaScript web part in Kentico 8.x.
Solution: Remove the comments!
In my limited testing, this issue does seem to be resolved in the newest version of Kentico 9.0. So hey if anything, consider this blog post as another reason to upgrade to the latest version of Kentico 9. Especially since Kentico 10 is right around the corner ...hopefully.
Wrapping Up
I hope that this quick tip saves at least one Kentico developer out there a head scratching moment. I know that we were sure puzzled for a few minutes on it. Now my team's conversation has changed to how do we prevent this in the future. Automated regression testing was once solution thrown out there, sometimes that's possible, and sometimes not depending on your client's budget. I would be interested to hear if anyone else out there has ran into this issue. If you have leave a comment at the bottom of the page. Thanks!
