In 1.16 I’ve added the ability to expand the code beyond the page border by setting it as large as it needs to be to accomodate the code within. Enable the setting “Expand code beyond page borders on mouseover” under Settings > Crayon > Code, which is disabled by default. I’ve also added a new toggle which expands and contracts.
I ran into the issue where some users had an older version of Fancybox on their sites and needed to provide my own version to work with Crayon. So I put together a modification of the original script which allows you to initialise Fancybox when you need it and with different objects to what it’s usually provided. By default, Fancybox will apply these once the script is loaded: (window, document, jQuery) And it will initialise jQuery.fancybox. If I want to have my own version running independently, I’d need to provide it with a jQuery instance and a custom attribute name, say “crayonFancybox” so I can use my version without accidentally using the old Fancybox on some users’ Wordpress installs.
window.fancyboxInit = function (window, document, $, fancybox, undefined) {
// Original Fancybox script content goes here
};
Now if you include jQuery and two different Fancybox scripts in the same page, they won’t clash:
<script type='text/javascript' src='http://code.jquery.com/jquery.min.js'></script>
<script type='text/javascript' src='http://yandex.st/jquery/fancybox/1.3.4/jquery.fancybox.min.js'></script>
<script src="https://raw.github.com/aramkocharyan/fancyBox/master/source/jquery.fancybox.init.pack.js" type="text/javascript"></script>

<script type="text/javascript">

var jQueryCrayon = jQuery;
fancyboxInit(window, document, jQueryCrayon, 'crayonFancybox');

(function($) {
	$(document).ready(function() {
		console.log("old", $.fancybox); // Old version
		console.log("new", $.crayonFancybox); // My new version
	});
})(jQueryCrayon);

</script>

<body>

See the JS console!

</body>
The only downside is that you must use $(elem).crayonFancybox instead of $(elem).fancybox in your scripts. See a demo, and download the script.    
Crayon’s internal post management determines when the rest of the system should kick in. When you save/edit a page, Crayon searches through the content and keeps a reference to the post in the database if it contains any Crayon tags. When you save/edit a comment, the same process takes place. When you load a page, Crayon goes through all the posts requested (for a single page, this is usually just a single post) and only checks those known to contain Crayon posts. For each of these, Crayon captures any tags used and keeps them in internal PHP memory. When the page or comment content is requested by Wordpress, Crayon steps in, highlights the code in the tags it captured earlier and replaces the original tags in the content. This means that only those pages that contain Crayons are ever checked for Crayons, meaning much more efficient than looking through every single post on the blog for Crayon tags! In Crayon 1.12, I’ve added a feature in the settings page to display all the posts that contain Crayon tags. It will also list all the posts which have Crayon tags in their comments, even if the post itself doesn’t contain any. This is crucial to ensure Crayon kicks in and highlights the code in those comments. As an added safety measure, when you refresh the settings page, Crayon will manually go through all the posts in your site and update the list of those containing Crayons in the database. So if anything funky happens that somehow messes up this list, refreshing the settings page should sort it out.
If you’ve been using Crayon Mini Tags or other syntax highlighters with syntax like: [php title="testing"]some code[/php] Or any other legacy Crayon tags: $[crayon lang="php" title="testing"]some code[/crayon] Then you might like to convert your blog’s old code format into a better standard: <pre class="lang:php decode:true" title="Testing">some code</pre> The benefits are backwards compatibility (if Crayon is disabled or you use another highlighter) and the ability to use the Crayon Tag Editor in the visual editor of Wordpress). Note: decode:true means that the code is encoded, so any < characters in the visual editor are really &lt; in the HTML editor to ensure they are valid HTML entities. Say I have this in Wordpress, switching to the HTML editor: From Crayon 1.12 there is a new setting in the admin: At the moment there are no detected legacy tags in any of my blog posts or comments. Lets add one: Now in settings, we see the button available: Clicking it will convert your legacy Crayon tag! Refresh the editor to see the change: And of course, it should look exactly the same on the front end: If you keep using the legacy tags and Crayon is disabled, it looks like this: Since the legacy code is just text in the editor, it looks like text if Crayon isn’t enabled. The <pre> tag however looks much better as preformatted plain text, and it hides all of your settings in the class attribute. One warning however, is to always backup your database before converting your tags - since this will change your post/comment content it’s safer to have something to rollback to. The beta version of Crayon (1.12 at the time of writing) can be downloaded from GitHub. UPDATE: As of the latest version, converting legacy tags now has an “encode” option. If selected, any legacy tag where the “decode” attribute is missing (neither true or false) has its code encoded and decode=”true” specified. This is useful if you have been using < and > instead of &lt; and &gt; in your [php] tags for example - this method is dangerous since disabling Crayon will mean these tags will be recognised as HTML tags. So something like this will actually be executed rather than displayed as code: [html]<script>alert("bam!")</script>[/html] The correct approach is to use encoded characters in all your HTML output; including your code snippets.
I’ve added bbPress support into Crayon since 1.11. Make sure you enable the setting “Display the Tag Editor in any TinyMCE instances on the frontend”, which is off by default from v1.15 to reduce the number of needed resources. This is needed to display the Tag Editor for any other frontend TinyMCE editors you may have (including but not limited to those in bbPress). I’d appreciate any bug testing (and fixing?!) from people who use bbPress, since I’ve made a lot of changes to the Tag Editor javascript in this beta hopefully everything works as smoothly.
Due to a recent request I’ve added a feature in Crayon that allows you to specify a line range (e.g. 3-5) of code to include in the Crayon. Only the lines in this range are actually used in the output. Here’s the original: And with a range: You can also provide the range as a single number and only show one line in the output. This will be released with Crayon 1.10.2, but it’s available now at GitHub.
My take on the JavaScript module pattern. I needed to call init() when ready.
(function($) {

	window.moduleName = new function() {
		var base = this;

		// Internally visible
		var pvt = '123';

		// Externally visible
		base.init = function() {
			console.log('init');
		};
	};

})(jQuery);

console.log(moduleName.init);
 
This will cause any element to blink, with the option to provide a duration for its disappearance.
$.fn.blink = function(time) {
	var time = typeof time == 'undefined' ? 200 : time;
	$(this).hide(0).delay(time).show(0);
}

// Example
$('.something').blink();