The Code4Lib Journal published its second issue today. Much thanks to all the editors and authors, especially Eric Lease Morgan, coordinating editor this time around.
It’s been exciting, these last few months, watching the Journal really get going. We’ve had a large number of impressive submissions for this and future issues, a good amount of word-of-mouth advertising, and nearly 15,000 visitors to the site since the launch of the first issue.
I still haven’t gotten around to blogging about many of the hacks we’ve made to WordPress to make all this happened, nor have I created all the plugins that I need to create to ease our workflow and enhance our presentation. Eventually…
If you’ve tried to use code samples in WordPress, you might have noticed unexpected behavior from the WYSIWYG editor. It will edit the whitespace inside of <pre> tags, leaving you with some poorly formatted, hard-to-read code. Today, I set out to stop that.
What causes this?
Whenever the WYSIWYG editor opens, it sends the content of the post through a few filters. You can find most of these in wp-includes/formatting.php. The culprit here is the function wpautop. This function runs a long list of regular expressions to make your content a little prettier and better formatted. But we don’t want that to happen to our <pre> tags; they’re pre-formatted. We want those left alone. To do that, I had to find a way to keep the content of the <pre> element from going through that filter.
WordPress’s plugin system allows you to change its behavior without altering the core code, so you don’t have to re-alter it every time you upgrade. As easy as it would have been, in the short-term, to just edit wpautop to make it behave properly, I wanted a longer-term solution that would be easier to share with other WordPress users. Therefore, a plugin. Continue reading →
