This is a series of posts wherein I share the dev mistakes that I used to make, and hopefully help others in doing so! Also, I reserve the right to publish these either on Tuesdays or Thursdays. As long as the title is cheesy and alliterative, I’m happy.
Back when I was a young developer just learning the ropes, I did some silly things. One of them, as you can probably guess, was developing live (making changes on a live server) instead of locally (on my computer). I was full of excuses:
“But this site barely gets any traffic! If I make a few changes live, who will notice?”
“If I code this site right on a staging server, I don’t have to migrate the site from my computer to the server because it’s already there!”
“Setting up a local server sounds hard and I’m lazy!”
I’ve heard it all, because at some point I’ve said it all. First, let me walk you through the three main ways one can code a site:
Worst: Developing on a live/production site
In my defence, even back in the old days, I didn’t do this too often. After all, it would be ridiculous to develop a full new site from scratch in a public location where everyone could see it. But, not gonna lie, sometimes when I was asked to add new features to an existing site, I found myself being both lazy and overly optimistic and just quickly doing it live on the server.
Overly optimistic? Yep! I was assuming that I wouldn’t make a mistake that would mess up the live site and even potentially ruin my reputation as a developer. And when it’s easy to take out a whole site with a single missing semicolon, this was actually a pretty real risk.
Sub-Worst: Making changes to a WordPress theme using the built-in editor
noooooooooooooo
If you are going to go ahead and make changes to a production WordPress site right on the live server, please never do it in the built-in editor. While HTML and CSS are pretty forgiving, one can royally screw up stuff in PHP (see above about missing semicolons taking out whole sites), and if you make a mistake in the online editor, you risk taking out your entire site with a White Screen Of Death™ and not even knowing why. Usually you’ll only take out the front end of your site, but in some cases, you can even lock yourself out of the admin pages. Know what’s super fun? Trying to restore your website when you can’t even access your website. Don’t do it, kids!
Don’t let this happen to you!
Better: Developing on a staging site
So, you’ve decided instead that you’re going to develop your site on a staging server or a test site that only you and the client have access to. That’s obviously way better than making changes on a production server, because at least it’s private and if you mess something up, the public doesn’t have to know! Yay!
That being said, here’s what I don’t like about this method:
- Working off the server means that you’re at your server’s (and your Internet connection’s) mercy. All servers have outages at some point, and because the universe totally hates you, it’ll obviously happen when you need it the most.
- FTP is slow, dudes. There’s a lot of waiting and reloading with this method, and I’m impatient.
- Your super secret site might not be so super secret. I’ve found other developers’ “secret” “staging” sites in Google before when I wasn’t even looking for them. Oh noes!
- Once you’ve given out the secret address for your client to see, they can/will see all the further changes you make, and might see some mistakes that you make (or wonder what happened to the site when it’s taken out by the missing semicolon of doom). When I’m troubleshooting code or trying new features, I’ll often do strange things like outline elements in weird colours, use cats and Samuel L Ipsum as placeholders, and will occasionally console.log(‘some very profane things’). I don’t necessarily need my clients seeing all of that (though, to be honest, I’m pretty shameless about the cats).
Best: Developing locally alongside a staging site
Naturally, my favourite solution is to always develop sites locally (on my computer) so that the only people who can see the site in its incomplete state are me, myself, and I. Then, when I’ve finished, I upload the site to a super secret staging server (which I’ve made sure is hidden from search engines) for the client to see. Any time I have changes to make or bugs to fix, I go back to my local server to make the changes, and then push the changes to the staging site when I’m good and ready. This might sound tedious, but trust me, it’s saved me a lot of grief.
This method is awesome because:
- Developing locally is crazy fast! No need to wait for changes to upload or for pages to reload. There are various apps that’ll refresh your browser automatically every time you save a file, and let me assure you, this is a magical experience from which there is no turning back.
- I can screw up as much as I want in the comfort of my very own computer. Clients and the public only ever see the site when it’s in good shape. Life is much less embarrassing this way.
- Client-facing sites will never succumb to the White Screen of Death™ due to a missing semicolon.
- During development, I always have an up-to-date version of the website on my computer in case anything happens to the server.
Coming up next: How I develop locally!
Are you intrigued about the idea of developing locally? If so, stay tuned! My next post in this series will go into detail about how I develop locally, which programs I use, and other fun tips and tricks. And if you disagree with any of this, that’s cool too! Feel free to share your perspective in the comments below or reach out on Twitter.
“White Screen Of Death™ ” made me giggle way too much. So many developers need to know that developing locally is the best way to go! Who wants to see all of your mistakes? Yikes! Let alone developing on a live site. It gives me anxiety just to think about it. Thanks for sharing Dara! Can’t wait to read your follow up article. :)
I like you’re writing style :) Looking forward to reading the next part of your series.
As I was reading this I also realized that I REALLY like your body copy typeface. I need to replace mine cause it’s lame and this is feeling like a pretty decent alternative right now!
Thanks Alicia :D You can totally use my body typeface, since it’s just a Google web font! There are tons of great ones available through Google Fonts these days. I say go for it!
Great tips!! My boyfriend (who is also my developer) codes in a local environment so I was nodding along reading this. Also, I’m dying at Samuel L. Ipsum. HAHAHA.
Using Samuel L. Ipsum makes my day about 100x better, not gonna lie. hahaha.
Love it! Can’t wait to read the next one – I’ve JUST started poking around in wordpress and could see the potential major issues of using the editor, but couldn’t (with my only slightly more than barebones web knowledge) figure out an alternative. Teach me. :D
That’s awesome that you’re starting trying things out! Once you start using a good editor (like Espresso or Sublime Text, among many others) instead of the web editor you’ll never go back!
I love this! Definitely good advice for a web development student like me! I can’t wait for the next installment!
Hi,
I am soooo waiting for the next step ! I know it’s better to do it locally but as I am still new to web development I am also sooo scared that when I move my site from local onto the server it will mess things up and I won’t know how to fix it :-( I’m scared of the URL part actually. I don’t really know what to do about them technically speaking..
But one question. If you develop a WordPress site live but with a maintenance mode is it ok? A little bit ok??
Hi Chrys,
There are plugins that’ll do most the moving part for you if you’re intimidated by that part! Some people I know swear by Backup Buddy to migrate sites from one server to another — it apparently make the process pretty painless. Maintenance mode is definitely better than developing when the site is totally live, but I’d rather not have to take a site down at all!
Hi Dara,
Thanks for your answer. I was wondering, have you already used backup buddy? It’s expensive but it looks convincing…I wonder if it’s a good investment or not..
Kind regards
I learned this the hard way. I used to develop live, break something and then have to fix it. Sometimes this happened at a ridiculous rate depending on what I was doing!
I love MAMP!
Any plans to do the next installment? I’m so exited to see your process!
Pingback: How to set up local development sites in MAMP | Wordius
Just wanted to add a comment in support of developing remotely. I have Netbeans set up to send changed and saved files straight to my development server. It has it’s problems on occasion but most of the time it’ll upload the files just as fast as locally (of course that would depend on internet connection speed too). I use htaccess usernames and passwords to hide the site from the public (and my customers) until I’m ready to show it to them.
The biggest problem I had with working locally was that the server settings, php versions, php extensions etc. should be as close to your live environment as possible otherwise you’ll run into compatibility issues as soon as you deploy your site. This is especially true if you’re trying to do anything fancy with third party API’s (learned this the hard way last week doing a Booxtream integration) and htaccess can be a pain in the bum with that too (you think php white screen is bad.. not nearly as bad as htaccess errors which tell you nothing useful just a big nasty error page!)
While coding you should have php error reporting on so you won’t get the white screen of death (I hate that screen too :) and of course working on a live site always has risks which is why I develop themes etc on a development server beforehand unless it’s content changes or something really basic in which case I live the thug life and just do it.
The most important thing of course is just to keep doing it and refine your own working process. Right now I’m trying to get my head around why I should use Gulp and Bower to speed up my workflow (seems like total nonsense to me and adds a lot of extra rubbish in my theme files not to mention slowing development).. anyhoo that’s my 2 pence on the subject :)
Hi Lisa, thanks for sharing your workflow. I always like to hear about how other developers work! Your setup of using Netbeans to save files directly to your development server sounds really interesting.
I hear you on the issues of different server settings. Most of the sites I build are deployed on fairly standard LAMP servers so I haven’t run into too many problems, but I’ve heard that using Vagrant (instead of something like MAMP) can help with that since you can be very specific about matching your local environment to your server.
I have to say that using Gulp has had a HUGE impact on my development workflow and has really sped up and improved development for me. Being able to completely automate all sorts of tasks (Sass preprocessing, CSS minification, image optimization, sprite generation, JS linting, live reloading, etc. etc. etc.) has been a total game changer. I use my own starter theme with a gulpfile.js already configured and ready to go, and I have the node_modules folder excluded in the Git repository so the extra files only exist on my local copy, not remotely. I highly recommend giving it a try! :)
Thanks for the tips and info Dara. Gulp does look like it could be really useful, I’m just having difficulty adding it to my current workflow. The info about the node_modules could help me since of course I don’t want them uploaded to my server but even copying them locally takes forever. Could you give me some more info on how you use Git in your workflow? I really want to learn to work smarter but the amount of bloat (comments, almost useless files, extra libraries installed etc) all these tools create just seems to defeat the purpose, and also I’m probably just not smart enough to figure out how it all works without getting a headache hah :)
Tools like Gulp are definitely a bit of a learning curve and time commitment while you’re setting them up and learning how to use them, but once you’re past that part it’s all pretty straightforward! I did a talk last year about optimizing the WordPress dev workflow, which includes some info on Gulp and Git, so maybe that’ll give you some ideas! Here are the slides: http://daraskolnick.github.io/WCTO-dev-workflow/
Ello again. Thanks so much for linking to those slides. I think I finally get the idea now. I think I was feeling a bit overwhelmed with all the tasks and bits and bobs needed to run gulp, bower, sass etc. Your slides have helped me break it down so now I’m developing our new site using underscores (much less bloat than roots.io), bitbucket and finally sass! Wooot. Will still have to see about git deployment, but I’ll take it bit at a time. Sometimes I feel like a right thicko trying to keep up to date with best practices but the way you explained it made sense! :D