Life, and Processingjs in WordPress

It’s been ages since I last posted, but that’s mostly because I’ve been incredibly busy on other projects, teaching, and etc.  I’ve been recently named Computational Designer in Residence at Ravensbourne, in London, thanks in no small part to Will Pearson and his vision (which I emphatically share) of injecting more coding skills and exposure into the excellent digital design process already churning through the college.

Seen here is my version of “Tron Blur” originally by the talented Dave Bollinger, whose website unfortunately doesn’t seem to exist anymore. I used it in this post for an upcoming workshop on SuperCollider by Simon Katan.

Towards that end, I’ve been experimenting a lot more with JavaScript and HTML5 in the hopes of shedding Flash forever, for good, but the amount of competitors in near-endless.  Competition and diversity are great things but too much of a good thing causes a stomach-ache (or headache).

The good news is that the newest Processing alphas (almost a full 2.0 release!) support building directly to JavaScript via the excellent ProcessingJS, which translates the Java-inflected Processing sketches into JavaScript code right inside the webpage, saving tons of time and work.

I figured this would be a nice way to share code and sketches here on my WordPress blog, because the old Java-based Processing applets either ran slow (or not at all) or had permissions issues on corporate or university computers. And plus, Dan Shiffman did it, so why not?

Ok, first off – this solution is hugely problematic. Read on if you’re brave, at the end I’ll tell you why:

To get it working, I first installed the Processing JS pluginfrom Keyvan Minoukadeh (you can do it directly from your WordPress admin control panel, just go to Add New Plugin and search for “Processing” but make sure to get the right one).  Then, I customized it to use the latest ProcessingJS by downloading it (or, run the new Processing 2.X versions and export as Javascript, then look in the sketch folder for the “processing.js” file) and copying over the new “processing.js” file to the /YOURBLOG/wp-content/plugins/processingjs/js/ . Then, edit the processing-js.php file in /YOURBLOG/wp-content/plugins/processingjs/ and change the top lines to:


add_action('init', 'pjs_init');
function pjs_init() {
 //wp_enqueue_script('processing-js', plugin_dir_url(__FILE__) . 'js/processing-1.0.0.min.js');
 wp_enqueue_script('processing-js', plugin_dir_url(__FILE__) . 'js/processing.js');
 wp_enqueue_script('processing-init', plugin_dir_url(__FILE__) .'js/init.js', array('jquery'));
}

Now, make sure it’s activated. BUT, there’s a final step.  By default, WordPress adds these incredibly annoying paragraph (“<p>”) tags all over the place when you hit Return.  These will break your code!  So you can properly edit, you’ll need to turn off this automatic feature by placing the following line of code in your theme’s header.php or functions.php file:

remove_filter( 'the_content', 'wpautop' );

Now, if all has gone well, you can create a new post, and in HTML mode you should see a “processing” button.  Click that and an area will appear for you to type Processing code into.  Just remember that images and data files should be referenced using URLs – so upload your images first, then copy the whole URL and paste it into your loadImage() calls, or upload your data to a folder on your website and do the same.

The problem with all this is that there should simply be a shortcode like [processingjs] that disables all the content filtering such as for greater-than and less-than and paragraph breaks when you hit return.  Without these, your code will break because bits of it will silently and magically be transformed into HTML codes instead of JavaScript code. Bleh.  If I get a chance I may take a crack at this, otherwise maybe someone else will come up with a better solution.