Skip to main content

This site requires you to update your browser. Your browsing experience maybe affected by not having the most up to date version.

We've moved the forum!

Please use forum.silverstripe.org for any new questions (announcement).
The forum archive will stick around, but will be read only.

You can also use our Slack channel or StackOverflow to ask for help.
Check out our community overview for more options to contribute.

General Questions /

General questions about getting started with SilverStripe that don't fit in any of the categories above.

Moderators: martimiz, Sean, Ed, biapar, Willr, Ingo, swaiba

Editor strips out Javascript tags


Go to End


23 Posts   10103 Views

Avatar
BigChris

Community Member, 63 Posts

1 March 2010 at 10:54am

Romeo said "It seems that this solution, which was working in 2.3.3, no longer works in 2.3.4. The 'valid_elements' and 'extended_valid_elements' are no longer set in LeftAndMain.php but in cms/_config.php, via HtmlEditorConfig::get('cms')->setOptions. But now using the wildcard approach to allow all tags, as mentioned above, doesn't work - the content of the Javascript tags is still being stripped. I presume something else now needs to be done instead (or as well). Any suggestions? "

Did anyone find a solution to this?

I have edited /cms/_config.php and changed the section with
HtmlEditorConfig::get('cms')->setOptions(array(

to have 'valid_elements' => "* [ *"

This did not work. And I also tried to use all the options as stated by TinyMCE for Full XHTML rule set.

This does not appear to work in Version 2.3.6. but apparently used to work in LeftandMain in early versions of 2.3.

Is there a possible bug in 2.3.6 for this?

Or am I looking in the wrong area?

Cheers
Chris

* ",

Avatar
edk

Community Member, 39 Posts

5 March 2010 at 7:28pm

I am glad there is a thread on this topic...I have run into a couple of instances in the past weeks where there were solid use cases for careful and responsible use of script tags in the content block. [*Note: I am a strong advocate of keeping the scripts out, and agree with Hamish's post on the use a library like JQuery to bind events via selectors - an elegant solution in that use case].

I have been pondering these two use cases though:
1. Inserting "code blocks" into a page say for a tutorial. The newer version of [url=http://alexgorbatchev.com/wiki/SyntaxHighlighter]http://alexgorbatchev.com/wiki/SyntaxHighlighter recommend using his script tag solution over the <pre> tag.
2. If you use a service like Wufoo.com for third party forms, you can easily insert these forms into your content by using <script> tag. A very user friendly way to get forms integrated into pages quickly.

I have been stewing especially over use case 1 because I like the method of storing sample code in external file not in <pre> tags....but I am still not convinced that updating the config and opening up script tags within the content pane is justified. In fact today I just saw a great use of gist from git hub to display snippets in an external site...but again it uses the <script> tag to insert into the page...

Thoughts.

-chango

Avatar
bummzack

Community Member, 904 Posts

5 March 2010 at 8:14pm

Hi chango

In my opinion, the syntax highlighter should really be used with <pre> tags instead of "script". The simple reason is, that it will also work nicely in RSS feeds, a text-browser etc. That's especially important if you're writing tutorials.
If you really want to load external files into your tutorial, how about something like that:

<a href="link/to/myfile.js" class="codelisting">Code listing for example A</a>

Then use jQuery AJAX to load in all the links marked as "codelisting" (as plain text), replace the link with the contents of the file (wrapped in <pre>) and then run the highlighter. Should be possible with only a few lines of jQuery code and you'll have external files, that also degrade nicely in RSS or text-browsers etc.

Your second use-case would probably be more complicated to work around, but I don't know this wufoo thing and their API. And since SilverStripe got such a nice UserForms module, the need for that won't be that big I guess.

Avatar
bummzack

Community Member, 904 Posts

5 March 2010 at 9:01pm

Just to prove what I said, here's the script that loads code via ajax and displays it using the syntax highlighter. Requires jQuery and the SyntaxHighlighter script mentioned by chango.

;(function($) {
	$(function(){
		$('a.codelisting').each(function(){
			var linknode = $(this);
			$.get(linknode.attr('href'), function(data){
				var pre = $('<pre class="brush: js"></pre>').text(data);
				linknode.replaceWith(pre);
				SyntaxHighlighter.highlight(pre);
			});
		});
	});
})(jQuery);

In the content editor you would then enter:

<a href="link/to/myscript.js" class="codelisting">Code listing A</a>

Avatar
edk

Community Member, 39 Posts

10 March 2010 at 10:51am

Edited: 10/03/2010 10:52am

Hi Banal,

You make perfect sense about the <script> tag not rendering on RSS Readers etc....your solution here is great! Thank you. It is far better than using the <pre> tag in the WYSWIG b/c I was noticing that the TinyMCE was trying to be too helpful and on subsequent edits would insert <br /> tags inside the pre tagged code. Arghhh!

So your solution here of adding a link which is rendered via way of some AJAX magic is hands down clever. Why?
1. If someone has js disabled then the link is still available to them to get the code (progressive enhancement - check).
2. The code stays out of the WYSWIG which I find far easier for editing and reference. You could store that code in the assets directory (there are some pros and cons with that - with updating) or elsewhere on a separate directory.
3. Using your link solution I think is quicker than the <script> solution b/c I think the js solution would "block" downloads etc...(I have not validated this)

Lastly I edited your code just a little bit to make it completely flexible to use with other code brushes. Essentially I added a rel attribute to the link, which Jquery then uses to write that brush type into the rendered tag.

Example:

;(function($) {
   $(function(){
      $('a.codelisting').each(function(){
         var linknode = $(this);
         var brushType = linknode.attr('rel');
         $.get(linknode.attr('href'), function(data){
            var pre = $('<pre class="brush:' + brushType  + '"></pre>').text(data);
            linknode.replaceWith(pre);
            SyntaxHighlighter.highlight(pre);
         });
      });
   });
})(jQuery);

and then simply add the rel attribute in the link:

<a href="link/to/myscript.js" class="codelisting" rel="js">Code listing A</a>

For anyone interested there is a full listing of brush types check our the documentation on Syntax Highlighter. Lastly don't forget to laod your required brushes in the page.

Thanks again Banal for your solution. It is a fantastic approach.

-chango

Avatar
bummzack

Community Member, 904 Posts

10 March 2010 at 11:21am

Hey chango

Glad you like my approach. Your extension for different brushes is also a good enhancement. Of course it would be even nicer if the content-editor could somehow specify the code-type (brush) without having to edit the HTML source.
My first thought was to use different classes to select in the styles dropdown, but that could become cumbersome with lots of brushes.
Maybe the brush could instead be specified via URL. Eg. link/to/myscript.js?brush=js. Then simply read out the brush from the URL using JavaScript.
The rel attribute works just as well though.

Avatar
edk

Community Member, 39 Posts

10 March 2010 at 11:32am

You make a great point, and I have also thought over a "true" repeatable solution. Willr had mentioned in SS2.4 that there maybe the chance to use "Short Codes" like in wordpress....it is actually really similar to the TextParser post that you did on SSbits not too long ago. Anyone who hasn't read this check it out: http://ssbits.com/embedding-youtube-or-vimeo-inside-your-text-content-using-a-custom-textparser/

I really think a solution like that would be most flexible b/c the code in the back end could then discern the required brushes and load them dynamically as opposed to adding the required brushes to the page template manually. A short code or snippet would also abstract a lot of the other detail away from the WYSWIG, which in this instance is probably a good idea.

I may take a stab at that sometime to get a fuller more repeatable solution running.

-Chango

Go to Top