HTML Demos

I posted a video a few weeks ago of a plugin I was working on to manage HTML demos in WordPress. I’m publishing the code now as version 0.1 — meaning it works, you should feel safe about using it, but it’s not finished. For example, I just realized that the only Javascript library you can include on your page is jQuery.

I think it would be cool to be able to have options to do some post-processing. So, maybe Markdown and HAML for HTML. Obviously SASS and Less for CSS — maybe Stylus? CoffeeScript for Javascript would be nice.

One other thing that I think would be really awesome is if you could associate a demo to a post somehow. Then I could add some extra template tags like the_demo_link(), which would automatically grab the link to the demo for that post. Or maybe another tag that would automatically grab the link for the associated post? Anyway there’s a lot we can do with this.

It’s on Github. I’d love to take pull requests, or any bug reports filed through the issues tracker.


Lots of web people have some way of hosting demos on their site. The one I always think of is CSS-Tricks, but there are many others. I’ve actually done it in the past on my site, but no matter how easy I made it for myself, it was always too hard so I just never used it. But that’s dumb because I publish everything else around here with WordPress and WordPress is really good at keeping track of stuff like this. So I decided to create a custom post type for HTML demos inside WordPress.


The plugin is actually smart enough to insert the HTML after the_content(), which is cool. The styles and scripts are enqueued into the header through external files that the plugin also generates. Bottom line, this should work out of the box with any theme.

If you want to customize how your demos look though, it’s pretty easy. Just add a single-html_demos.php file to your theme and WordPress will use that to generate those pages. So, just like you would customize any other template, you can customize the template for your demos.

View in Plugin Directory Download on Github

Version Control Themes with Git

I really like being able to deploy my current theme to production from my local environment. I can test locally and then deploy to the live site when I’m ready.

Some people like to keep all of WordPress under version control. I don’t think that’s useful unless you’re a WordPress developer. You’re unnecessarily tracking changes to WordPress and your environment. I like to keep each theme and each plugin in it’s own repository. They’re separate projects so they should get separate repositories.

I constantly go back to this great tutorial when I have to set up a bare git repository on a production server.

Facebook: Building the WordPress plugin

WordPress developers will be familiar with many of the problems described here.

I’ve been thinking about this quite a bit lately — writing open source software (where you have a whole variety of environments to support) will be entirely different from working at a company like Facebook (where you probably know more specifically what the servers will look like). Each is going to have his own challenges to think about. Once you get used to developing with certain challenges in mind, it’s probably not obvious what new challenges there will be in a different context.

Using LESS as a Live CSS Engine

It generally just seems like a bad idea to trigger processing of LESS (or SASS) with a page load. Honestly, CodeKit does so much more than just compile your stylesheet into CSS that it doesn’t even seem worth it to me. You should still be generating minified CSS and Javascript as well as optimizing your images. Plus the syntax checking I get on my Javascript. Not to mention all the cool stuff it does with my browser. I’d still be using CodeKit even if I didn’t have to worry about compiling SASS.

Andrew Powers:

One of the coolest things about implementing LESS inside of the framework is that we’re able to dynamically control colors and typography based on user selections. This allows us to design things well, while still giving users the ability to customize colors and type.

Since WordPress 3.4, there is a theme customizer built in that allows you to dynamically control colors and typography based on user selections. Otto has a couple of really good articles on how to use it. The first, How to leverage the Theme Customizer in your own themes, is a good introduction to the customizer. I was happy find that there’s even Javascript that reloads the page within the customizer if you choose a new color so you don’t have to save it and manually reload to see what it will look like (possibly only in 3.5 and up).

Users are able to actually add their own LESS in the admin options panel. They can use common variables for the background color or main fonts.

If your users want to write custom code for their theme, don’t add a textarea to your admin panel that allows them to write code, encourage them to write a child theme — it’s what they’re here for.