Rich Text Editor stripping out "onClick" from links?

I’ve noticed that after the 3.1 upgrade, the Rich Text editor is removing “onClick” code that I’ve added to links. Is this happening to anyone else?

Hi Conan,

We were just testing this internally, and it does appear that the new version of TinyMCE present in Percussion 3.1 strips out onClick attributes. We’re going to investigate this further internally, but for now, can you tell me if you’d be able to simply relocate this onClick event handler to an external script, or would this require a significant amount of effort to rework? Thanks!

Hi Nathaniel,

The quick workaround that I found was to change the Rich Text widget over to an HTML Widget. The problem is that many of our end-users are not as comfortable with those.

Hi Conan,

While this may be the default behavior of the new TinyMCE editor, because this was not how the editor functioned in prior versions of Percussion, we’re investigating this issue as a bug currently. I will keep you updated as we work towards a resolution.

In the meantime, the workaround of moving this type of content into an HTML widget will certainly work, while a more future-proof solution would still be to relocate your onClick event handler to an external location.

Hi Nathaniel-

Can you provide more details on HOW to relocate the onClick event handlers? I’ve tried figuring this one out and am stuck.

Hi Debbie,

Sure. To start things out, here’s a good article I found on why web developers are moving towards using Unobtrusive JavaScript (separating JavaScript from HTML markup):…

Now, for example, say you had a link such as this:

My link

To relocate this JS code away from your HTML markup, you could give that anchor tag a class (or ID), select it with jQuery, and use the click() method to initiate your old onClick function when a user clicks on this anchor link.

The new link:

My link

The relocated JavaScript:

  $(document).ready(function(){ <br />
       $('a.myClass').click(function() { <br />
           XYZ <br />
       }); <br />
  }); <br /> </script>```   
In this example, _XYZ_ can be replaced by the JS code exactly as it appears between the quotes in the original example. The script block should be housed in either a global JS file, or one of your template’s Meta-data code insertion points. Let me know if all of this makes sense.

Thanks, Nathaniel. Will give this a try.

Hi Nathaniel,
We just realized that this also affects our document library, which has a unique Google Analytics code attached to EACH downloadable document. For that reason a workaround will be very time consuming (per our developer) so we are anxiously awaiting the resolution for this. Please keep us posted.

Hi Debbie,

At present, a fix for this issue is slated for our next release, version 3.2, which is being targeted for an early September release. Please let me know if this timeline will cause issues for you, and we can discuss alternate solutions.

Hey Nathaniel,
Let me know if you have any alternate solutions for this. We are having to revert back to the previous version this evening because we have a release scheduled for tomorrow night and need all the GA codes to remain intact.

Hi Debbie,

Actually, reverting back to the previous version was going to be one of my suggestions, and may honestly be the simplest solution if you are unable to relocate your onClick functions before the release you have scheduled.

Let’s face it. The Rich Text widget is probably the most powerful and most used widget of all of them. The fact that it will clean up bad code is a great idea, I just don’t understand why it cleans up “valid” code. I can understand that a “Rich Text” widget is for just that – rich text, and an HTML widget is for html, but if that is the case then it should be stated that the rich text editor only supports very basic html. There must be a configuration file or preference that can be set to allow or disallow certain code. Our sites use HTML5 and the Bootstrap framework extensively. For example, try to use a bootstrap Glyphicon in a rich text editor like; `````` the rich text editor strips it right out. I want to use Bootstrap markup and enhanced functionality like onClick in the rich text widget. Even with the recent enhancements to the HTML widget, they are not as easy for end-users to manipulate. I don’t mind that the rich text editor removes invalid code, but onclick, html5, and bootstrap markup can be valid.

I think the solution should be a preference to turn the auto-correction on or off. If that’s not possible, perhaps we can get a “Pro” version of the Rich Text editor that allows everything, and hey, if you enter invalid markup, then that’s your own fault. And if that’s not possible maybe Percussion should consider using a different rich text editor than TinyMCE.

Hi Conan,

This is great feedback, and we’ve been discussing some of what you said internally. I recommend you create a new topic of the “Idea” type outlining your proposed solution of a function to turn the markup auto-correction on or off in the RTE (by means of a “Pro” mode, or maybe a tag, similar to what’s in the HTML widget). Thanks!

I would definitely vote for the “idea” of being able to turn off/on the auto-correction!

Thanks Nathaniel and Debbie, I created it as an Idea topic.

Did anything come of this Idea?

The TinyMCE Editor shipping with v3.3.4 (the OP was referencing 3.1) still behaves in this manner so I don’t believe anything became of the Idea from Mr. Green.

TinyMCE is highly configurable in most cases. I haven’t yet had time to snoop around and find the config files in CM1. When I do I’ll post here with any success I have.

Hi Stuart,

This issue was reported to have been have resolved in version 3.2. We will research to determine if a regression has occurred.

Any modifications to TinyMCE configuration files are not supportable and may compromise other functionality in the product. Instead, I would encourage you to post any feedback around future enhancements to the TinyMCE as ideas.


Hi All,

The onClick issue was fixed. However it would be nice to have more control over the “auto-correction”.

This topic could probably be marked as “closed/fixed”.

Chris Hill, if you want to follow the topic that I created as an Idea, go here: