A Cowboy Coding Horror Story
All WordPress developers have a cowboy coding horror story, or several. Or if they don’t, it is because they are very new or very very lucky. So gather around the campfire, and I’ll tell you the story of my most disastrous cowboy coding adventure.
My cowboy (well, in my case, cowgirl) coding experience didn’t look quite this dramatic, but it felt about this bad.
I had a client with a simple WordPress site. It was a TwentyEleven child theme – it probably took me about two hours to create the site. Then the client wanted a very simple change to the sidebar. I don’t remember now exactly what the change was, but it was something trivial, like adding a title to the sidebar. Whatever it was, it should have been a 5-minute task, and it involved editing a theme file. I didn’t have FTP access to the site, but it was such a simple little quick fix that I edited the theme file directly in WordPress’s built-in theme editor.
If you’ve ever worked in the theme editor, you know where this is going. I edited the file, clicked Save, and….. white screen. Because of some little syntax error (probably a missing semicolon), the site was down. I couldn’t access the dashboard. Even worse, I couldn’t fix my syntax error because I didn’t have FTP access.
On top of all of that, I was doing this at 8:00 in the evening.
So I had to call my client and interrupt his evening to tell him that I had broken his website. Then it got worse – he didn’t have FTP access either, and the only guy in the company who had FTP access was on vacation in Hawaii. I guess the only consoling grace in all of this was that Hawaii was a few hours behind, instead of a few hours ahead, so at least we didn’t have to wake up the vacationing guy in the middle of the night to get the FTP password. And we were even luckier that he had access to the FTP information while he was on vacation. He was able to get that information to us within a few hours, and I could fix my little syntax error, and we got the site back up.
But meanwhile, their site was down for several hours, which makes them look bad, and I lost a lot of credibility with that client.
So what did I learn from that experience? Several things:
- Never use WordPress’s built-in editor on a live site! Never ever! And if you do use it, install a plugin that gives you syntax highlighting so that those little syntax errors are easier to find. But mostly, don’t ever use it on a live site!
- Never edit PHP files on a live WordPress site if you don’t have FTP access. No matter how simple the task, you will forget a semicolon, or forget a comma between items in an array, or something trivial that will cause a white screen. You must have FTP access to edit PHP files.
- If you need to edit PHP files, use a staging site. This experience was one of several that inspired us to create WP Stagecoach. I could have installed WP Stagecoach and created a staging site within a few minutes. If I had syntax errors on a staging site and the staging site was down, it wouldn’t matter. WP Stagecoach provides FTP access to staging sites, so I could have edited the files with FTP. It would have only added a few minutes of work for me, and would have saved hours of site downtime, not to mention my relationship with the client.
Every developer has at least one story like this, which is why we created WP Stagecoach. We wanted to make it as easy as possible to eliminate cowboy coding.
Do you have a cowboy coding horror story? Feel free to share in the comments! Don’t be embarrassed – we all do!
Image credit: Cowboys falling off horses
