Professional WordPress Development: Tools

Professional WordPress Development: Tools

This entry is part 3 of 3 in the series Professional WordPress Development

In this series, we’ve been reviewing topics for Professional WordPress Development aimed at those who are looking to improve their professional WordPress development skills.

At this point, we’ve covered strategies and environmental practices, but we’ve yet to examine some of the tools that are more common in WordPress development. In this article, we’ll be taking a survey of the various tools, utilities, and plugins that contribute to building and maintaining successful projects.


Plugins

Whenever I’m setting up a local development environment for a WordPress project, I make sure that I have the following tools installed and at my disposal. Many of these have come as a result of experience, recommendation of more experienced developers, or personal preference.

As with most things in this series, these are merely suggestions – they aren’t the rules or the standards by which you measure your configuration.

JavaScript Debuggers

JavaScript Debugger

As we covered in the first article in the series, a portion of WordPress is written using jQuery and most themes and plugins include it, as well. As such, debugging JavaScript is a core need for professional development (especially when working with plugins or themes that abuse loading their own scripts or versions of jQuery).

  • Firebug is arguably the most popular JavaScript debugger for Firefox
  • Chrome’s Console is extremely useful and includes a built-in JavaScript debugger

Both utilities also offer the ability to write JavaScript directly in the console so that you can evaluate functions, expressions, and statements without having to edit your core files, reload the page, test, and repeat.

Regardless of the debugger that you prefer, make sure you have one running in your browser as it makes locating errors and resolving them much easier.

Theme Unit Test

Theme Unit Test

The WordPress Theme Unit Test isn’t a unit test in the traditional sense. Instead, it’s an XML file that you can import into your WordPress installation for the benefit of your theme or plugin that gives you a set of posts, pages, authors, comments, images, etc. to make sure that you’re formatting data correctly.

If you’re building a plugin, it provides mock data that your plugin can run against to see how it would perform against actual, live data.

If you’re an advanced developer or are looking to actually begin testing with WordPress, then be sure to review our series on Unit Testing WordPress.

Developer Plugin

Developer Plugin

The Developer Plugin is a relatively new plugin that was created by the VIP team at Automattic that aims to provide developers a suite of tools specifically for helping us develop better.

The plugin includes…

  • Support for standard WordPress.org sites and VIP sites
  • Debug Cron
  • Rewrite Rules Inspector
  • Log Deprecated Notices
  • VIP Scanner
  • Grunion Contact Form
  • Monster Widget
  • Beta Tester

…all in one plugin with a simplified interface. Personally, this is my de-facto plugin for local WordPress-based development.

Theme Check

Theme Check

Theme Check is another plugin that I recommend for development that will evaluate your code against the current version of the WordPress API and provide notices, warnings, recommendations, and errors based on your code.

Though I believe that some of the recommendations are occasionally out of date, its set of warnings and errors are almost always accurate and provide a heads up on things that you should resolve prior to shipping your work.

Debogger

Debogger

Debogger is a useful plugin especially if you care about W3C validation and are interested in query optimization and well-written PHP. The plugin will intercept all information that is transmitted between your project, WordPress, the server, and the browser, and then return any debug information and notices into the footer.

This plugin has been exceptionally useful for me as it catches minute PHP errors that don’t always register because of the dynamic nature of the language.


PHP

Log Display

As far as PHP logging is concerned, I typically like to have the following configuration:

  • Development and Staging Environments: Render all errors and warnings to the browser and the log file
  • Production Environments: Render all errors and warnings to a log file

This makes it easy to locate, detect, and resolve errors that exist in your project in the least intrusive way based on who is viewing your site. Clearly, Development and Staging and meant for you and a set of testers whereas the Production Environment is meant only for users.


CSS and JavaScript

You can easily improve the speed at which the browser loads your site by minifying and combining your stylesheets into a single file. Of course, this is somewhat of a hassle if you do it manually. Luckily, there are a variety of tools available.

My weapon of choice is CodeKit.

CodeKit

For CSS, it includes support for both LESS and SASS, minification, and also has built-in dependency management.

For JavaScript, it also includes support for both JSLint and JSHint both of which are considered to be JavaScript “code quality” tools. We know from previous articles that WordPress has its own coding standards, but they’re more closely related to PHP than anything else.

Using a JavaScript Lint tool – such as JSLint or JSHint – you’re able to have automated code reviews that ensure that your code is up to a standard and evaluated each time you save the file.

Again, this is just my preferred method of managing external resources – there are a variety of other ways to do this. The bottom line is that you should look into performing some type of code quality evaluation, preprocessing, and minification when available for both CSS and JavaScript.


Conclusion

At this point, we’ve covered Strategies, Environments, and Tools for Professional WordPress Development. Of course, there is much more information available on this topic.

Considering this blog has a community of dedicated developers, I’d love to hear what you guys keep in your toolbox, as well. Be sure to share it in the comments and link up any resources so that the rest of us can benefit from it, as well!


Other parts in this series:Professional WordPress Development: Environments
Note: Want to add some source code? Type <pre><code> before it and </code></pre> after it. Find out more
  • Pingback: My Stream | Professional WordPress Development: Tools | My Stream

  • Pingback: Professional WordPress Development: Tools | Qtiva

  • Pingback: How To Schedule A Post In WordPress | Open Knowledge

  • Pingback: Professional WordPress Development: Tools

  • http://www.customicondesign.com Custom Icon Design

    I just use dreamweaver for code. and use firefox + firebug to check the features. I havent use CodeKit. For the css creator, I think use LESS and SASS is good.

  • The MacEwan

    Great series Tom, Thanks. Theme Check, Debogger, Codekit (SASS,Compass), Sublime Text 2, Mamp Pro, CS6, etc: are tools I use all the time. For non-WP clients I use Pagelime to let them update the content without fluffing the code. I try to update my workflow/tools as new and reliable technology hits the masses, but atm I’m happy with the tools I have. Now if I could just find a way to make ALL IE6 users upgrade, I could spend even more time on design.

    Thanks again man…

    • Tom McFarlin
      Author

      Sure thing – thanks for sharing your thoughts!

  • Pingback: Professional WordPress Development - Tom McFarlin

  • http://ahrengot.com/ Jens Ahrengot Boddum

    Nice write-up. A couple of really cool tools in there.

    • Tom McFarlin
      Author

      Thanks a lot, Jens!

  • http://twitter.com/twittem Edward McIntyre

    I have never heard for Debogger. Sounds interesting, I will have to check it out.

    • Tom McFarlin
      Author

      Yeah – I’m a fan. I use it in a lot of theme-specific work.

  • Ian

    Thank you for this excellent series of articles.

    As I continue learning this is the kind of professional workflow I am working towards.

    A quick question on the dev plugins listed. I’m assuming when you commit changes from dev to staging you exclude those plugins so they don’t end up in the staging or production environment. Not up to speed with deployments yet so how do you handle that?

    • Tom McFarlin
      Author

      You’re exactly right – you don’t need to run the plugins in Production. I think it’s actually okay to do it in Staging, but it’d depend on your audience.

      If your development team is the one testing, it’s probably okay; if it’s your end-users, it’s probably best to leave ‘em off.

  • http://www.elimcmakin.com Eli McMakin

    For Windows:
    XAMPP, NetBeans, github, dropbox, Chromes code inspector, and the browsers “view source”. All free.

    • Tom McFarlin
      Author

      Yep – thanks for sharing these!

  • Pingback: HostNine Weekly | HostNine Company Blog

  • http://nuvomedia.dk/wordpress.html Nicolai Busekist Ohlsen

    Lovely list of tools. I wasn’t familiar with especially many of them, so I have a lot of reading to do. Thank you.

    • Tom McFarlin
      Author

      Sure thing!

  • http://memeLab.com.au/ Tim Osborn

    Great list, tx.. I use XAMPP, codekit, fire-php for firebug in my workflow, but I’ve wanted to extend the ‘Debug Bar’ plugin (not mentioned here), which I haven’t managed yet.. I’d be happy to hear about any tutorials for that one! cheers, Tim

    • Tom McFarlin
      Author

      Thanks for sharing your resources – maybe one of the other contributing authors can share their tips for Debug Bar..

  • Pingback: Monday Morning WPTuts Round-Up | HostNine Company Blog

  • romuloctba

    i hate that codekit is a mac app. I have no mac.

  • http://www.agnelwaghela.bammz.net/ Agnel Waghela

    Hi Tom, a simple question – Codekit is only for Mac Users, any equivalent or similar tool for windows Users?

  • http://tanekpage.weebly.com/ Garrison Blackburn

    I select PHP sources because It is one of the first developed server-side scripting ‘languages’ to be involved into an HTML source documents rather than getting in touch with an external details information file to process data.