22975 Posts in 11620 Topics by 2826 members
|Go to End|
1 March 2010 at 10:54am
Did anyone find a solution to this?
I have edited /cms/_config.php and changed the section with
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?
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...
5 March 2010 at 8:14pm
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.
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.
var linknode = $(this);
var pre = $('<pre class="brush: js"></pre>').text(data);
In the content editor you would then enter:
<a href="link/to/myscript.js" class="codelisting">Code listing A</a>
10 March 2010 at 10:51am Last edited: 10 March 2010 10:52am
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.
var linknode = $(this);
var brushType = linknode.attr('rel');
var pre = $('<pre class="brush:' + brushType + '"></pre>').text(data);
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.
10 March 2010 at 11:21am
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.
The rel attribute works just as well though.
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.
|Go to Top|