Conditionally change JetPack Infinite Scroll trigger to “click” or “scroll”

Earlier today I was trying to change the “type” for JetPack’s Infinite Scroll behavior to use “click” only for the front page. For all other archives I wanted JetPack to use the standard “scroll” type (you know, the namesake for Infinite Scrolling).

(In a hurry? The solution is at the very bottom of the post.)

JetPack has a bunch of filters available, and the developers even had the foresight to provide a conditional to toggle this behavior based on whether or not the site footer is displaying widgets. Each of the JetPack Infinite Scroll Settings is explained extremely well in the documentation. The setting designed for what I wanted to do is called footer_widgets.

This setting expects a boolean and, if true (footer widgets are present), JetPack will automatically convert the event trigger to “click” in order to allow visitors to see the footer. My first thought was that I could throw is_front_page() right here in the settings definition. My immediate second thought was, “no, that won’t work.”

You see, when the theme support for infinite scroll is registered we’re on the after_setup_theme hook, which is much too early for WordPress to know which template is being loaded.

Digging in, I found a filter mentioned in the documentation named infinite_scroll_has_footer_widgets designed expressly for more complex logic. This is perfect, I thought. Surely this could be as easy as hooking the is_front_page() callback to the filter (i.e. add_filter( 'infinite_scroll_has_footer_widgets', 'is_front_page' )). Nope; this filter is also evaluated before the template conditionals know where we are on the site. Foiled again!

Ah ha! There’s a filter named infinite_scroll_settings we can override! Nope, this is run too early, too.

Finally, Ben Gillbanks (@BinaryMoon) came to my rescue:

He was exactly right. The filter infinite_scroll_js_settings, designed for altering the settings just before they’re passed into JavaScript, works because its parent function is hooked to wp_footer.

Thanks Ben!

If you’ve got a more appropriate filter or an even better solution, I’d love to hear it!

Serve Missing Media from a Production Server via Apache/Nginx

When working on a website locally, it can become quite tedious to pull down all media from a production environment – particularly if you just need to spot-check one or two key areas. In some cases, the production sites I work with have media folders that are more than 1GB (!!) in size. In fact, it’s not entirely uncommon for a large site with a lot of history.

Several months ago I saw someone tweet a simple solution to this, but I didn’t take note of the URL anywhere and it quickly slipped into the ether. Googling for phrases like “apache redirect missing images to production server” or “serve missing images from remote server using apache” or “display live site images on development site” yielded unproductive results.

Then, today, while wishing once again for a solution to my dilemma, I found it!

To save others (and my future self) the struggle of trying to find this solution, I’m documenting it here.

In both of my examples below, make sure you swap for your production server’s URL. And note that these snippets expect the URL structure to be the same between servers (they should be, if you’re working with a true staging copy of a production environment).

Here’s how to tell Apache to serve missing files via remote server:


Note: If you’re working with WordPress, make sure this directive appears before the WordPress-generated rewrite rules in your .htaccess file. Otherwise, WP will catch the missing file URL and route it to a 404 internally.

And, here’s how to tell nginx the same thing:


How about as a WordPress plugin?

You’re in luck! If you’re using WordPress and you’d prefer to slurp up those missing images (so you’re not always dependent on a remote server), you can use the plugin Uploads By Proxy. This plugin will fetch each missing image from the remote server and load it into your local uploads directory for future use. For my use cases, though, I just wanted to see the images on my staging site, not actually copy them and eat disk space.


Becoming a Better Developer: Week 1 Review

This past week has been absolutely packed with new knowledge. I’ve distilled it as best I can for now. I hope future travellers will benefit from this as much as I have.

Getting Started

This past week I read the first four chapters of Clean Code and several relevant blog articles:

Then, on Saturday, I attended the WordPress and Backbone.js session at

I’ll talk about each of these in turn below.

Clean Code, Chapter 1 – Clean Code

Honesty in small things is not a small thing.

This is the omen that kicks off the book, actually belonging to the foreword rather than the first chapter. I really appreciate this quote, much as the author does, because I value the small, the finite, the detailed. Small things matter, and they make all the difference. It reminds me of another quote I greatly enjoy…

It’s always the difference that makes the difference.

Ponder, for a moment, your favorite brands and your favorite experiences. What makes them special? What makes them memorable? I guarantee it’s not their broad generalities. Indeed, it’s their details – their uniqueness from other similar, but different things – that make them special and memorable to you. And, I argue, it is for these very same reasons that the details in your code matter.

It is through practice in the small that professionals gain proficiency and trust for practice in the large.

Attentiveness to detail matters when programming. It means the difference between code that functions properly, and code that brings an entire production site to a halt due to a misspelled variable or missing semi-colon.

A fascinating statistic that the author presents very early in the book is that studies have found “consistent indentation style was one of the most statistically significant indicators of low bug density.”  If you’re lackadaisical about how you’re indenting your code, you’re probably less specific about a lot of other things, too.

Making your code readable is as important as making it executable.

This point, I feel, is paramount to everything else that this book covers. Humans will read your code often – maybe not that one small module tucked away in the recesses of the codebase, or that one-off function you had to hammer out at the end of the day specifically, but by-and-large code that you write will be read again by humans. It will either be read by someone else, or by future-you (which, if time has elapsed more than two weeks, makes future-you as good as a total stranger). What will they think when they read this code? Can they read this code? How frustrated do you feel when you cannot read or understand code that someone else has written?

Have you ever been significantly impeded by bad code?

Where does bad code come from? We run into it often, but why is that? I wager that improper planning, poor time management, and unrealistic expectations are the three most common factors of bad code.

Perhaps you felt that you didn’t have time to do a good job; that your boss would be angry with you if you took the time to clean up your code. Perhaps you were just tired of working on this program and wanted it to be over.

The best way to combat writing bad code is to remember that small things matter and that, ultimately, going slow will lead to working fast.

Working Fast = Working Clean

The only way to make the deadline— the only way to go fast— is to keep the code as clean as possible at all times.

This is a phrase I want to have enlarged, bolded, italicised, highlighted, underlined, and framed. It should be a permanent fixture at the top of every code editor, before the signature line on every contract, and in the footnotes of every email and project communication.

Sloppy code slows everyone down. If may feel faster as you’re writing it, because you’re just flying through line after line as you scramble to complete each function. But think about the gravity of what you’re doing – you’re writing the very lining of your own tomb!

How will you extend that code going forward? How will your code interact with the code of your teammates? How will it respond to the third-party integration you now need to include as part of phase 2? What happens when you or the client uncover a bug – will you even be able to trace it and correct it?

If you want to go fast, if you want to get done quickly, if you want your code to be easy to write, make it easy to read.

An inordinate amount of time is dumped into maintaining bad code. It’s an alarmingly and depressingly large statistic. Don’t burn away hours of your future because you couldn’t spare a few moments in the present.

Incremental Improvements beat No improvements

Try and leave this world a little better than you found it… — Robert Stephenson Smyth Baden-Powell

The next time you sift through a project, take some time to change code for the better. To quote the author once more, “Improve a variable name, break apart a function that is doing too much, see if you can’t eliminate one small bit of duplication…”

Clean Code, Chapter 2 – Meaningful Names

One difference between a smart programmer and a professional programmer is that the professional understands that clarity is king. Professionals use their powers for good and write code that others can understand.

If you want your code to be understandable to strangers (and I’m including future-you, here), long after you’ve written it, you would do well to choose meaningful names for the things you write. Files, classes, functions, and variables should all be named in such a way that they are completely obvious and even pronounceable.

That last word there, pronounceable, isn’t a prerequisite for names that I had fully considered before reading this book. Now it’s a concept I haven’t been able to shake loose from my head. A function or variable that is pronounceable, say, convert_usd_to_eur(), is far, far easier to verbally reference to your coworkers than one named, say, UsdToEurCnv().

A consistent lexicon is a great boon to the programmers who must use your code.

This is a principle I’ve tried to maintain for almost my entire career as a developer. Not strictly for the sake of other developers, but for myself, too. Using a consistent, predictable naming pattern makes it very easy to correctly guess what something is likely named within a project. If you take no other tips away from this chapter, let it be this one: name things consistently!

Shorter names are generally better than longer ones, so long as they are clear. Add no more context to a name than is necessary.

A long descriptive name is better than a long descriptive comment.

Be concise, but be clear. “Post ID” is better than “The ID of the post”. However, “ID” is not better than “Post ID”. However, while striving for brevity, remember that it’s better for your function or variable name to be descriptive than it is to provide a descriptive comment.

People are afraid of renaming things for fear that some other developers will object.

Don’t be afraid to rename something in this age of “Global Find and Replace”. As the author suggests, you’ll likely surprise someone, but that is far better than the alternative of further cementing a poorly named item in your project.

Clean Code, Chapter 3 – Functions

The first rule of functions is that they should be small. The second rule of functions is that they should be smaller than that.

I love this excerpt, and the paragraph that surrounds it. The author cannot justify his assertion that smaller functions are better, except his four decades of experience in writing functions of all shapes and sizes. The shorter a function is, the easier it is to read, and the smaller the space for bugs to hide.

Your functions should tell a story.

Every function in this program was just two, or three, or four lines long. Each was transparently obvious. Each told a story. And each led you to the next in a compelling order. That’s how short your functions should be!

The program referenced in the quote above did some pretty neat and seemingly advanced stuff, and even still it could be broken down to functions that were an average of four lines long. That’s a pretty lofty goal to aspire towards, but a goal worth achieving nevertheless.

The implications here are that any nested structures currently found in your functions (if and switch statements, iteration loops, etc) are better suited in their own separate functions.

Functions should do one thing. They should do it well. They should do it only.

Functions that do one thing cannot be reasonably divided into sections.

Break apart those large functions! Make sure every function has a single purpose, and remove everything else it’s doing until that purpose is met. It is OK if a function’s sole purpose is to call three other functions, but make sure its name clearly reflects that purpose (e.g. find_and_delete_invalid_subscriptions() – This function is clearly doing two different things because the word “and” appears in its name. If those two things are two different function calls – find_invalid_subscriptions() and delete_invalid_subscriptions() – that’s a-o-fine).

Your function promises to do one thing, but it also does other hidden things. Sometimes it will make unexpected changes to the variables of its own class.

If a function conditionally behaves in multiple different ways, or it modifies something outside of the scope of its single, solitary purpose, its doing too much. Refactor that function in such a way that it does its one obvious purpose, and put the other bits into a separate function.

Functions should either do something or answer something, but not both. Either your function should change the state of an object, or it should return some information about that object.

On Function Parameters…

The ideal number of arguments for a function is zero (niladic). Next comes one (monadic), followed closely by two (dyadic). Three arguments (triadic) should be avoided where possible. More than three (polyadic) requires very special justification— and then shouldn’t be used anyway.

This is something I want to explore more in-depth, and I’d wager its worthy of a blog post all its own. I agree that fewer parameters is preferred to many (e.g. $args = array() vs $param1, $param2, $param3, ...), but I’m not so sure how I feel about “zero arguments”. That is something I’ll need more time to explore.

Clean Code, Chapter 4 – Comments

Nothing can be quite so helpful as a well-placed comment. Nothing can clutter up a module more than frivolous dogmatic comments. Nothing can be quite so damaging as an old crufty comment that propagates lies and misinformation.

While reading this chapter I found myself disagreeing with the author quite often. You see, I’ve always found code comments and inline documentation to be tremendously helpful – both while reading and writing code – and he maintains the position that comments are a crutch and too-often clutter up the codebase.

Comments are a great way to get your thoughts down on how you think a function should be written, and what generally needs to happen, in plain English. They’re also a great way to see a quick summary of what a conditional statement may be testing, or a helpful note about why a particular section is written in such an obviously non-optimal way (e.g. “This function checks for [something] in this way because [some other method] isn’t available at runtime”).

After wrestling with many of his points over the weekend, I’m starting to shift my position.

Don’t comment bad code — rewrite it. — Brian W. Kernighan and P. J. Plaugher

[W]hen you find yourself in a position where you need to write a comment, think it through and see whether there isn’t some way to turn the tables and express yourself in code.

Replace the temptation to create noise with the determination to clean your code. You’ll find it makes you a better and happier programmer.

[Good] comments do not make up for bad code.

Clear and expressive code with few comments is far superior to cluttered and complex code with lots of comments.

Most of my struggles throughout this chapter came to an abrupt end when I encountered the above quotes. Prior to this I saw our author as a simple comment hater. When I read, and then re-read these lines, though, I started to evaluate the many ways in which I misused comments in my code.

Don’t waste precious minutes of your limited time on this earth adding comments to poorly-written code. Put those minutes to better use and improve the code. You won’t only be improving your own life, you’ll also be improving the lives of everyone else who will have to interact with that code in the future. You’ll be doing everyone a better favor, too, by improving the code than you will by merely describing it.

Blog Posts – Objects, Singletons, and Dependency Injection, oh my!

I don’t have much commentary to add to the blog articles I read, but I do highly recommend reading them. I’m of the mind that singletons (classes that are designed to be instantiated exactly once) are generally bad and to be avoided, for all the reasons Michael Toppa raises in his article.

I’ve personally been drawn towards using singletons across a number of projects. I liked working within a class structure because of the clean namespace it afforded me. Even as recently as this week I’ve placed code inside of a class that I only intend to instantiate once, globally. I know it’s bad – my awareness of my habitual problems is the entire reason I’ve committed to this 16-week series!

Bonus reading! This weeks serendipitous look at Object-Oriented Programming reminded me of an article I read back in August titled OOP is Not Your Hammer by John Hann.

WordPress and Backbone.js

wpsession6_thumb_pastI don’t think I can say enough good things to fully do this session justice. The three presenters, K.Adam White, Carl Danley, and Zack Tollman each did a phenomenal job in breaking down Backbone and making it approachable, even to a beginner. I’ve had a keen interest in Backbone.js for over a year now, but I just didn’t have the ambition or fortitude to take it on until after watching this session. Now I can’t wait to put it to use. I’ll probably start using it this week, in fact.

If you’re interested in adding structure to your javascript – even if you’ll never actually use Backbone.js – I highly recommend watching WordPress and Backbone.js and learning from the experts. Carl Danley, for example, does a great job guiding how to break apart a project and think about it as discrete, manageable pieces before even laying a line of code.

In Conclusion

To conclude this past week’s study, I leave you with a quote from the end of the Foreword to Clean Code:

Learning to write clean code is hard work. It requires more than just the knowledge of principles and patterns. You must sweat over it. You must practice it yourself, and watch yourself fail. You must watch others practice it and fail.

But never forget that your real goal is to tell the story of the system, and that the functions you write need to fit cleanly together into a clear and precise language to help you with that telling.

We are in for a long haul. This work will not be easy, but it will be worth it. Everything else builds from this foundation, so it is important that we get it right.

Next Week

Over the next week, starting today, I’ll be reading chapters 5-8 of Clean Code.

Are you keeping up? I’d love to hear your thoughts on any insight you’ve gained or any of the commentary I’ve added above. Leave some feedback in the comments!

Becoming a Better Developer: Week 1 Schedule

This week marks the beginning of my 16 week “Becoming a Better Developer” course.

Starting today I’ll be reading the first four chapters of Clean Code:

  1. Clean Code
  2. Meaningful Names
  3. Functions

I’ve looked ahead, and I’m really excited by some of the excerpts I’ve read. I’m particularly enthused by Uncle Bob’s strong emphasis on short, uni-tasking functions and using meaningful, descriptive, and pronounceable names. Just following those two pieces of advice alone can dramatically improve anyone’s code.

I’ll report back on Friday with my key take-aways and highlights.

Have you read this book? What am I in for? Please let me know in the comments!

Becoming a Better Developer

As I stated last week, for the next four months I’m putting myself through code school.

Objective and Plan

In order to do this right, I’ve outlined a 16 week plan that has me reading 5 books and recording what I’m learning. Every Monday I’ll write about the chapters I intend to read and what I expect to learn, and every Friday I’ll write about what I actually learned along with key take-aways. I think it would be great if you were to follow along every week and share your experiences in the comments. I could certainly use the encouragement, and I’m sure you can benefit by learning something new (or being reminded of something they forgot), too.

My main objective is simply to become a better developer. I realize this is largely an unquantifiable intangible, but I know that I (and anyone else following along) will become demonstrably better for putting forth the effort. I can say this with certainty because I’ve never heard of anyone getting worse – or remaining stagnant – after investing sixteen weeks of effort into a sole area of focus.

Demonstrable improvement may surface in any one of the following ways:

  • Increased expedience in solving complicated problems
  • Better solutions to existing problems
  • Cleaner, simpler, human-readable code
  • Improved architecture across the entirety of a given project
  • Code that is easier to test, debug, and extend
  • Jealous co-workers, friends, acquaintances, and arch-nemeses.

Required Reading

Below are the six books I intend to read, in order, over the next 16 weeks. I’ve linked to the kindle edition of each (not affiliate links), and have included the current price on Amazon. You’re welcome to acquire these books however you like.

  1. Clean Code [17 Chapers, 315 pages] – $21.39
  2. The Pragmatic Programmer [8 chapters, 260 pages] – $22.99
  3. Design Patterns: Elements of Reusable Object-Oriented Software [6 chapters, 360 pages] – $27.49
  4. Guide to Building Testable Applications in PHP [16 chapters, 68 pages] – $20+
  5. Refactoring: Improving the Design of Existing Code [15 chapters, 413 pages] – $29.99
  6. WordPress Coding Standards Handbooks [4 pages] – $0

Total Investment: $121.87
Total Reading Commitment: 62 chapters, 1,420 pages
Per week: 4 chapters, 88 pages

In addition to the required reading, I’ll also be participating in every session taking place at

If you want more to read, see my post on additional recommended reading for developers.

Learning Goals

My learning goals are pretty fuzzy at the moment. I’ve learned that there is so much that I don’t know that I can’t possibly know what it is I need to learn or how it will benefit me in the future. That’s a very convoluted way of saying, “I want to learn whatever is written in the books I’ll be reading, and I hope it’s all good for me.”

That said, there are a few things I hope to learn (or better understand) by the time I’m done here. Once I’ve concluded the 16 week course I’ll circle back and update this post with a nice concise list of things actually learned. Until then, here are just a few for-instances:

  • Learn and leverage the common best-practice mnemonic devices (e.g. SOLID, DRY, etc.).
  • Understand the merits and best approaches of Test-Driven Development (TDD).
  • How to efficiently refactor crufty code without destroying everything.
  • How to recognize a problem as an identified pattern with a repeatable solution.
  • Better understand the purposes and capabilities of Object Oriented Programming (OOP).
    • Specifically: when to use constants, static, public, private, or protected properties and methods.
    • How to avoid “singletons” and other the many other pitfalls OOP-beginners typically make.
  • Understand and better leverage Model-View-Controller (MVC or MV*)-style architecture.
  • Better understand and implement RESTful practices.
  • And the coding utopia: the best ways to write cleaner, efficient, and more effective code.

Course Schedule

Week 1: Clean Code, Chapters 1–4
Week 2: Clean Code, Chapters 5-8
Week 3: Clean Code, Chapters 9–12
Week 4: Clean Code, Chapters 13–17
Week 5: Pragmatic Programmer, Chapters 1–4
Week 6: Pragmatic Programmer, Chapters 5–8
Week 7: Design Patterns, Chapters 1 & 2
Week 8: Mid-Semester Reflection + WP Developer Handbook
Week 9: Design Patterns, Chapter 3
Week 10: Design Patterns, Chapter 4
Week 11: Design Patterns, Chapter 5
Week 12: Design Patterns, Chapter 6
Week 13: The Grumpy Programmer’s Guide To Building Testable PHP Applications
Week 14: Refactoring, Chapters 1-5
Week 15: Refactoring, Chapters 6-10
Week 16: Refactoring, Chapters 11-15

Join Me?

If you’re at all interested in this, I urge you to follow along. The only real financial commitment is the cost of the books – if you choose to buy them – which is far less cumbersome than a single college credit, I can tell you that much. Join the mailing list or leave a comment below and let me know you’re following along!


Becoming a Better Developer: Precursor

Here are a few posts I’ve read recently that have helped get me in the frame of mind for the semester of learning I’m designing for myself.

Be sure to check out this recommended reading for developers post I put together on Sunday, and the Back to Basics post I published on Monday. On Friday I’ll work on published the list of books I intend to read over the next 4 months and the specific topics I intend to study and write about over that course of time.

Have a great article to recommend that I missed? Leave a comment!

Back to Basics

This year, my goal is to become a better developer than I was last year. Now, that’s no different than my goal in previous years, and if you’re a developer it should be pretty high on your list of goals as well. However, this year I’m approaching the goal in a measurable, tangible way.

I’m sending my self to code school.

I’ve been building websites since 1996. I cut my teeth on rudimentary HTML on a free Tripod-hosted website that some kindred spirit from the Yahoo! Chat: Programming chatroom helped me create. From the moment I learned that every site had exposed source code that I could view, dissect and emulate, I was hooked.

In the 17 years that have passed since I crafted my first HTML tag, the web has evolved and grown in amazing and magical ways. I have learned and grown with it, but certainly not in the same order of magnitude. In fact, I don’t even think the work I’m producing adequately demonstrates SEVENTEEN YEARS of education. This is largely my fault.

For the better part of these 17 years I have snubbed formal education and conventional learning. I haven’t attended a programming class of any kind or even so much as cracked open more than one or two programming books. Everything I’ve learned has been out of curiosity or necessity from project to project. In the folly of my youth I scoffed at the notion that I could learn something of value about our fast-paced industry by reading an already out-of-date book or enrolling in a behind-the-times college program.

What a fool I was.

Now, this isn’t to say I’ve ignored collective wisdom. Certainly not! I would not know any of what I have learned without the help of minds that are both brighter and more generous than my own. I owe a great debt to those who documented their work and put out blog posts, tutorials and other instructional materials. It is in their footsteps that I hope to follow.

This year I hope to undo all the damage I created by not taking my discipline seriously.

Developer Boot Camp

For the next four months I’ll be attending a self-directed semester of education. I’ve solicited book recommendations that every good developer is expected to have read, and I’ll be completing sample projects that I believe are important to learning the principles these books will teach. By the time the semester is over, I will be a demonstrably better developer than I am today.

Thankfully, I’ve already gotten a bit of a head-start. In June of 2013 I launched WPSessions, which has brought to me the personal instruction and expertise of more than 17 WordPress experts so far. I’ll continue to lean on that throughout all of 2014 as well, but the sessions there will only help supplement the more rigorous education I’ll be documenting here.

In my next post I’ll lay out the schedule I intend to follow, the required reading I plan to complete, and the specific topics I desire to learn and master.

Join Me?

If you’re at all interested in this I urge you to follow along. The only real financial commitment will be the cost of the books – if you choose to buy them – which is far less cumbersome than a single college course, I can tell you that much. Leave a comment here, or join the mailing list below, and I’ll do my best to help hold you accountable.


Recommended Reading for Developers – Building a Better Bookshelf

This year I want to become a measurably better developer. One way I hope to improve in that regard is by reading the best books that have been written on the topic of programming and development.

Now, I would consider myself a web developer – I’ve been building websites for the better part of 17 years – but I don’t consider myself a very good one. You see, in all this time I haven’t read more than maybe a single book on the topic. Everything I’ve learned has been from the web, and has been learned quite haphazardly at that.

Please help me fix this.

Leave a comment below with your best recommendation for required reading for a competent developer. Book, blog or otherwise.

The book doesn’t need to be specific to web development. In fact, I would love to read any book that leads me down the path of being a better thinker, doer, and problem solver. I’d love to learn about design patterns and how to efficiently solve problems in ways that have been demonstrated to work. The languages I work with most regularly are PHP and JavaScript, and I predominantly build websites using WordPress, but if your recommendation will teach me principles that extol the pillars of better development practices, regardless of language, I’m for it!

Here are some suggestions I’ve already received:

So, tell me, what book (or blog) are you shocked I haven’t already read at some point in the last 17 years?

Developing for Success

This post originally appeared on shortly after this event took place in 2011. I’ve resurrected it to include as part of my own blog.

WordCamp Chicago 2011 I presented on “Developing for Success -or- Any Fool Can Do This”. The talk encompassed how I took a leap of faith and launched StartBox and all of the challenges that come with that. Slides and resources are below.

(click here to watch on

You Can Do This!

Starting and running a business is easier than you think, but there are a lot of overwhelming challenges that can really break you down if you don’t have a plan or perseverance. My goal in the presentation was to inspire others to realize they already have the tools and resources they need to get started today and succeed.

An important caveat is that you must define success for yourself. If you chase after someone else’s definition of success (or your perceived version of what they think success means) you will always fall short. Another important reminder is that you cannot define success by specific attainable goals. Those are goals, they are not a living definition of success.

How I Define Success

Personally, I define success as: Spending most of my time doing something I enjoy, while generating more revenue than debt, in positive and meaningful ways.

If I’m missing any one of those three components I’m not succeeding because I’m either spending most time doing something I don’t like, generating more debt than revenue, or doing negative or meaningless work. Bleh!

My Presentation Slides

My presentation slides are available at SlideShare.


Leverage the resources that are available to you, there are plenty:

Configuring a Local Apache/PHP/MySQL Dev Environment in OS X

Update: If you’re just getting started now, I strongly recommend looking into Vagrant instead of rolling your own environment like I describe. I still use the exact environment I detail below, but am leaning towards Vagrant soon. If you’re a WordPress developer, specifically check out Varying Vagrant Vagrants (VVV) by 10up.



These are my personal notes that I use every time I reformat or get a new computer. I’ve curated these instructions over the course of 4 years, so they are littered with links to relevant source material and have been stripped down to the exact actionable steps I need to take to get up and running. As such, this post is mostly for my own benefit, and I will regularly update it as my process changes (usually with each new OS X release).

These instructions have been updated to specifically support OS X Mavericks (10.9), but will work with Mountain Lion (10.8), Lion (10.7), Snow Leopard (10.6), and Leopard (10.5). Running 10.4 or lower? You should probably upgrade 🙂

I might write some follow-up posts about using this setup to create a killer local WordPress Multisite installation, and also porting your dev environment contents to live in DropBox. If so, I’ll link them up here.

Why not just use MAMP?

If you’re wondering, I like to set up my local environment, instead of using MAMP, because I prefer to have it always available. I never liked having a separate application running just so I could access my local dev setup. Also, it has always bothered me that MAMP bundled its own copies of PHP, Apache and MySQL when the only missing component that doesn’t come pre-loaded with OS X is MySQL.

Help, I’m stuck!

It’s worth mentioning here that I’m not a very smart guy, which is why I’ve kept these detailed notes for the last 4 years. These instructions work for me, but they might not work for you. If you get stuck with an issue, I suggest googling around and sharing what you discover here in the comments. It will likely be much faster than asking me for help, and will benefit everyone who reads this (me included)!

A Quick Word about my Terminal Commands

In many of the terminal instructions I use my custom bash shortcut “sub” to open a given file in Sublime Text 2 via command line. You can substitute “sub” for your text editor of choice (e.g. “vi” for Vim, or “mate” for TextMate, or “subl” for the standard Sublime shortcut).

Install MySQL

Follow these steps, in order:

  1. Download DMG installer from
  2. Install MySQL
  3. Install MySQL auto-start
  4. Install MySQL pref pane
  5. Then, configure MySQL:
  6. In Terminal: sub ~/.profile
    1. Add this line to the file: export PATH="/usr/local/bin:/usr/local/sbin:/usr/local/mysql/bin:$PATH"
    2. Save and close the file.
  7. In Terminal: source ~/.profile
  8. Finally, configure MySQL socket (because OS X is looking in the wrong directory):

Configure PHP

These steps are really only to keep you sane while testing uploads and such in your projects:

  1. In Terminal: sudo cp /etc/php.ini.default /etc/php.ini
  2. In Terminal: sub /etc/php.ini
  3. Update upload_max_filesize to something like 64MB (L891 in OS 10.8)
  4. Update post_max_size to something like 64MB (L740 in OS 10.8)
  5. Save and close

Configure Apache

Update httpd.conf to enable PHP5 and Virtual Hosts:

  1. In Terminal: sub /etc/apache2/httpd.conf
  2. Uncomment the include for PHP5 (L117 in OS 10.8, L111 in older releases)
  3. Uncomment the include Virtual Hosts (L477 in OS 10.8, L623 in older releases)
  4. Save and close the file.
  5. If you’re running OS X 10.7 or earlier, you’ll also need to enable “Web Sharing” in System Preferences > Sharing.

Setup Virtual Hosts (

Update: If you’d rather have “*.dev” dynamically mapped to “~/Sites/www/*”, check out this great article on Apache zero-config development. Then, follow this article on using DNSmasq to redirect all .dev traffic locally.

For the example below, you’ll want to replace “” with your own custom URL, and “username” with your own OS X username.

  1. In Terminal: sub /private/etc/hosts
  2. Add the following line to the file:
  3. Save and close the file.
  4. In Terminal: sub /private/etc/apache2/users/username.conf
  5. Add the following lines to the file:
    1. <Directory "/Users/username/Sites/">
          Options FollowSymLinks Indexes MultiViews
          AllowOverride All
          Order allow,deny
          Allow from all
      <VirtualHost *:80>
         DocumentRoot "/Users/username/Sites/"
  6. Save and close the file.
  7. Finally, flush the DNS cache & Restart Apache (you’ll want to do this any time you edit your hosts file and virtual hosts setup):
    1. In Terminal: dscacheutil -flushcache
    2. In Terminal: sudo apachectl restart

In my setup I’ve registered to point to my ~/Sites/ folder, rzen.wp to point to ~/Sites/wordpress/, and rzen.php to point to ~/Sites/phpMyAdmin. This means I’ve created a separate pointer for each domain in my hosts file, and a separate <VirtualHost> container for each in my apache .conf file.


Apache Error Notes

Later, if apache ever goes south and starts spitting 403 Forbidden, or some other error, check the error log. You can open it from inside Terminal: sub /var/log/apache2/error_log

If the problem is “Symbolic link not allowed or link target not accessible”, confirm that your symlinked folder, it’s parent directory, et al, have sufficient permissions for owner and group (

Upgrading OS X?

Be aware that with every upgrade OS X is likely to overwrite your edits to Apache’s httpd.conf file. Specifically, you’ll probably need to edit /etc/apache2/httpd.conf once again and uncomment the lines for including PHP (L118) and enabling Virtual Hosts (L478).

This has at least been true both for upgrading to OS X Mountain Lion (10.8) and OS X Mavericks (10.9), and probably true in upgrading to releases before those.

The Optional (but recommended) Bits

Install Sequel Pro

This app is amazing, and it works brilliantly for manipulating both local and remote databases. And it’s free!
Download Sequel Pro

Install phpMyAdmin (if you hate living in the future and using Sequel Pro)

  1. Download latest version of phpMyAdmin from
  2. Unzip to ~/Sites/phpMyAdmin/
  3. Rename to
  4. On L36 change $cfg['Servers'][$i]['AllowNoPassword'] to true
  5. By default, your login will be root with no password

Install WordPress

  1. Download the latest version of WordPress from
  2. Unzip to ~/Sites/wordpress/
  3. Create a new database for your install via phpMyAdmin to use during installation
    • Database server will be localhost
    • Username will be root
    • Password will be blank
  4. Pro-Tip: Once installed, edit wp-config.php add define('FS_METHOD','direct'); somewhere before the “That’s All, stop editing here” comment. This will enable direct access to the file system when running automatic updates and make your local dev experience mui guapo.

Install Git

Visit and download + install the latest version. Done.

Install SVN

For some reason, beginning in Mountain Lion (OS X 10.8), Apple stopped packaging SVN with Mac OS. So, you’ll need to download “XCode Command Line Tools” separately by signing in as a Developer (after registering for a free account using your Apple ID) here:

Alternatively, you can download SVN directly from WanDisco: I recommend using 1.7+.

Enable SSL

If you ever have need to test a site or service locally using https://, my co-worker @jtsternberg has written up a wonderfully detailed step-by-step of his experience doing just that. You can read it here: How to set up SSL with OSX Mountain Lion’s built-in Apache