Working for years with Drupal's command-line tool drush, and more recently with Laravel's artisan, I've had occasion to interface with Xdebug in my favorite IDE, PhpStorm. Here's how I am currently working with all of these tools together.

Incidentally, if you've never tried a real debugger in your projects, you can check out my talk from WordCamp Orange County, "Let's Debug for Real", which was recorded from the audience, or a higher-fidelity version from a JavaScript perspective, my course Debugging the Web: JavaScript.

Here's how this will work: you'll do some initial configuration in PhpStorm and your local web stack, set a breakpoint somewhere in your code, then run your command line script from within PhpStorm. If all goes well, execution will stop at the breakpoint and you'll be off to the debugging races.


A debugger is essential for helping understand how code works. In my course Debugging The Web: JavaScript, I go over the essential parts of learning how to use one. These concepts are the same across pretty much all debuggers in common use, but there are also different helpful options available in each one that can be helpful.


I want to mention a couple small pieces of Mac software I use often, but think are very good: Dash and Pester.

Introducing the JavaScript Language cover If my training library were a treasure chest, it would be splitting its sides and busting its lock. Two courses on JavaScript are now available: Introducting the JavaScript Language and Getting Started with JavaScript Programming. If you've ever wondered what the deal is with JavaScript, these siblings will get you on the path to understanding.

The goal of these courses is to allow designers and other beginning programmers to understand the syntax of JavaScript, and how to start using it in real web projects. I treat it kind of like learning a foreign language, giving you to tools to read and write the language at a basic level (to start you off), and then getting into things like interacting with third-party jQuery plugins to add fun interactivity to a website. Becoming a competent programmer takes a fair amount of effort and time, as does becoming fluent in a foreign language (even if you're Tim Ferriss), but these courses should allow you to become, as the subtitle says, "a dangerous front end designer".

Try one, try both, just try them and let me know what you think! They're on sale at 20% off through late January and early February respectively.


I'm using the jQuery plugin Smooth Div Scroll on a site right now, and it's filling my needs nicely. The site is built on Drupal 6, and SDS requires jQuery 1.5, so some jiggery-pokery is needed to get all the right libraries in the right places. Drupal 6 includes jQuery 1.2, and the Drupal 6 version of jQuery Update only takes that up to jQuery 1.3. I had to mess with my theme's phptemplate_preprocess_page() function to make it all work. I don't think this is a common enough problem to bother posting about my specific solution, but here's the code I started with.

Once I was able to get it working on the pages of interest, Smooth Div Scroll has done a fine job.

The goal is a gallery with a smooth, horizontally scrolling image carousel, with thumbnails below for jumping directly to certain images. Smooth Div Scroll does this very well using its "moveToElement" method. The only problem is a distinct lack of smoothness — it just jumps straight to the image instead of animating.

I was pretty sure this wouldn't be difficult to fix. On line 384 of the non-minimized jquery.smoothDivScroll file, there's this line:"scrollWrapper").scrollLeft("scrollXPos"));

Just like it says, it sets the scrollable area's left position to whatever it's supposed to be directly, with no animation. To make it animate, replace that line with this:"scrollWrapper").animate({'scrollLeft',"scrollXPos")}, 'slow');

Same thing, but with a "slow" animation. Nice!

Most of the time when I build a website and use a content management system, I use Drupal. I recently finished a site that had basic needs, and decided to give WordPress a go. As I was going through it, I had questions about how to do certain things, and I'm going to post all the answers here.

  1. If there are javascript or other auxiliary files in the theme, and you want to link to them, use bloginfo() function, like this:

    <script src="<?php bloginfo('stylesheet_directory'); ?>/jquery.js"></script>

  2. If you want a page to look different than the other ones, or if there's some code that needs to appear on a particular page that can't be edited by regular users in the WordPress UI, you can make a special template for it. First, start the template with a comment link this one:

    <?php /* Template Name: A Special Page */ ?>

    Then when you create the page, there will be a Page Template selector in the right sidebar. Choose the template you created, and you're in business. I used this to set up a PayPal form and a bit of Javascript on a couple pages.

  3. In your template files, you can check whether you're the home page with the is_home() function, which returns true if you're on the home page (duh).

  4. The WordPress template system has many file names that are magical and recognized for certain purposes, and which can be called by certain functions. Here are a few of them. The complete list is on the WordPress Codex:

    • header.php - included in other templates with get_header()
    • footer.php - included with get_footer()
    • sidebar.php - included with get_sidebar()
    • style.css - the main stylesheet, but also contains the metadata for your template
    • single.php - used for single posts
    • page.php - used for single pages
    • archive.php - If it exists, this is used for anything that's browsed and isn't a single post (date archives, category archives, etc). Otherwise, index.php is used.
    • comments.php - included with comments_template()
  5. To include different selections of posts from the database, use the query_posts() function. For example, you can pull two posts from one category and then the five most recent posts from the entire pool of posts, and display them in different parts of the page.

  6. The WordPress Codex is a large and generally helpful resource. While developing a theme for WordPress, I spend a lot of time with the Template Tags page.

WordPress is very capable for building a complete website, or for just bolting on some quick page editing to an old school, no CMS, website. I like that WordPress feels relatively small and fast compared to Drupal. I do prefer Drupal for general content management and development for websites where blogging is not the major focus, but it's nice to have both tools available.

That about says it, doesn't it?

I was building a module for a site I'm working on, and I gave a module the same name as the current theme. One of the modules purposes was to make some blocks for the sidebar, so I included an implementation of hook_block() in the module. In Drupal development, this means you called the function modulename_block() -- if you already have a theme by this name, Drupal could also see this as themename_block(). Anyway, when I enabled the new module, all blocks on the page were gone. This is an issue other developers have seen, and the advice seems to be "don't do it".

So don't do it. I broke the block functions out into a separate module with a different name, and all was well.


A web host a client is using (who shall remain nameless) has been messing things up for us. Long story short, I needed to install my own copy of PEAR on the server, without SSH access, and without being able to use the [methods described] in the PEAR manual, because none of them worked for me.

I looked to see if anyone else faced the same problems, and I didn't turn up anything, but I did find this article that describes a way for people who don't have access to PEAR, and are afraid of installing it the usual way, can get into it. John offers a ZIP file with his PEAR files that you can upload to your server and use after a quick edit to your include_path.

I didn't want to use anyone else's files, but this did provide the insight I needed to get a manual installation working. As of this writing, when you install PEAR, you get a variety of directories: data, docs, php, tests, as well as several regular files. To install these on an uncooperative server, just copy the contents of the php folder to a directory on your server, and point your include_path directive to it, as John mentions on his page.

For the sake of posterity, I'll also mention the reasons I couldn't use the regular PEAR installation methods.


On a recent project, I had to learn and develop some code using [.NET] [1]. This was my first experience using a Microsoft framework for anything. I wouldn't call it an entirely pleasant experience, but it was also not entirely unpleasant. I want to talk a little bit about my experience with it, and mention a couple things that might help other people getting started with it.

Subscribe to RSS - Programming