Code Prettify

WallPhone

Code Prettify

mary

Can you be more specific about the problem(s) encountered with kses?

WallPhone

It seems to strip out a lot of the HTML tags that should appear inside the code block. Probably unfair, but my initial tests were done with CSS, HTML, and Javascript inside the code blocks

Side-by-side comparison here

WallPhone

I suppose if I convert the angle brackets to HTML entities beforehand this would fix more of the issues I found with formatters... Will look into this.

mary

kses is meant to be the last thing run before display.

At present the extension is a selectable formatter, which means it appears as an option for the user.

I could make a second version which is a global formatter, so that all you need to do is convert angle brackets and instruct the user to modify conf.php (see below).

Turn this:

'pre'  => array(),
'code' => array(),

into this:

'pre'  => array(
	'class' => 'prettyprint'
),

'code' => array(
	'class' => 'prettyprint'
),

'xmp'  => array(
	'class' => 'prettyprint'
),

WallPhone

Interesting. This was my first dip into the world of formatters, and an eye opener. I did notice in other applications that Kses is usually used as a last-level formatter--I saw it used in conjunction with Markdown for wordpress comments, which would have escaped the angle brackets inside the code blocks first. All the other formatters still caused problems that my escaping the brackets first would solve--for example BetterBBCode would escape the opening angle brackets but leave closing ones intact, which caused strange inconsistencies. I don't think it should be made global... the plain text formatters probably won't ever produce HTML that Kses could clean up, so they should be exempt, whereas a Markdown formatter that hasn't had its HTML feature crippled like the one in add-ons or a exploitable version of BBCode would most definately require Kses. I'm still not sure how to best 'chain' the formatters... part of me thinks it should be a user-configurable thing, and the other says there is no room for error so make unsafe formatters requre passing their output through Kses with the extension dependancy thing that is going to be in one of the next versions of Vanilla. Just noticed IE7 is clueless about line breaks in the example I linked earlier. ::sigh:: Another item for the todo list. :-)

pravin

IE7 ignores line breaks. Have you fixed this yet? Thanks for making a plugin that's really easy to use.

clearskys

Introduced \'s into the code on my system. So I added:

$text = stripslashes($text);

just before the last

return $text;

and it's all sorted again. Works nicely
Barry

flow

Over a year w/o a posting .. guess I must be http://redwing.hutman.net/~mreed/warriorshtm/necromancer.htm ;-) Can you please explain to me, how it can be that your second regex-replacing manages to strip all dollar-signs ("$") from code to be displayed? When I first looked into this issue I immediately dismissed your plugin as the cause because I thought I'd groked both regex's .. plus the comments backed me up there. Well .. after finding no other possible culprit .. I decided to switch CodePrettify off - the dollar-signs were back! And if I repeat those replacement calls in a simple testing scenario it confirms that it is the 2nd one that strips them .. since I don't think line-break replacing is actually an issue on our site I've simply disabled that call now. BTW: I've simply replaced the CSS/JS files with the latest "small"-package from the google-repository .. in case maybe others come by and wonder wether they can do that safely: yes :)