Having separate environments for development and production is great for testing, getting client approvals, and more, but it can sometimes trip you up when switching between the two. Here are a few tips to deal with common hang-ups when working between your development environment and production.
Different Colored Favicons
It can often be confusing when you have both the development and production sites open in the same browser. If you aren’t paying careful attention, you might accidentally change something on the wrong environment. A quick and easy fix for this is to change the color of your favicon in your development environment. With different colored favicons, you’ll be able to quickly distinguish which tab is which like so:
If you’re using WordPress, you can change your site’s favicon through WordPress’ customization options. In the dashboard, click “Customize” under “Appearance”. Select “Site Identity” and you should see the option to add or change your favicon:
If your favicon is stored in a Git repository, you may want to add it to the
.gitignore file to prevent overriding the production version when you do a push. However, this means that you will need to manually add the production version to the server.
Checklists are Your Friend
Anytime I need to duplicate content from dev to production, I create a checklist of everything I need to change. If it’s a simple content page, this might be overkill, but I often find myself doing more than just copying and pasting content. Depending on the page and the site, I may need to setup custom fields or custom post types, setup form fields, add pages to the main navigation, link pages together, adjust copy on other pages to account for the new addition, and more. As I’m setting things up in the development environment, I quickly jot down everything I had to do. This ensures I don’t miss anything when we move to production, and it can also help if another team member needs to takeover while you’re out.
Dealing with Absolute URLs
When working with links and images, you might have absolute URLs such as
http://praliedutzel.com/contact, where both the protocol and domain are specified. These types of URLs are great for reducing navigation errors, but you want to be careful if you’re moving content between development and production environments. Let’s say you have some content in a CMS you need to move to production, which includes an absolute URL to an image. If you were to simply copy and paste that content from the development CMS to production, your image would still be pointing to your development environment. If your dev site is password protected, the image will either fail to load or prompt the user with an alert to enter their credentials, depending on how you have things setup. Either way, this is a bad experience for users. If your dev site isn’t password protected, you could be exposing your development environment to the public.
You could switch to using relative URLs, where you don’t specify the protocol or domain such as
/contact. While this is technically easier to deal with, absolute URLs tend to be better for SEO. Instead of blindly copying content over, pay attention to any images or links that might be pointing to your development environment and update them. For most images, you should be re-uploading them to the production CMS anyway, so you can simply replace the image that would be pointing to the dev site.
A quick way to check that you don’t have anything pointing to your development site if it is password protected is to review new content additions to production in an incognito window or a different browser. This should bring up the credentials alert that you might not have otherwise seen if you were already logged in in your normal browser.