I bet a lot of us tend to have the production website and the development website up simultaneously a lot. It’s almost a developer cliché at this point to make some local change, refresh, refresh, refresh, refresh, and just not see the change, only to discover you were looking at the production website, not your local development website.
It’s just funny at first, but it’s frustrating if it happens a lot. It’s also totally avoidable by having an obvious visual¹ difference between the two sites. An easy way to do that? Different favicons.
There is no real trick to this. I literally just have a different favicon.ico file in development than I do in production. On this (WordPress) site, I only version control and deploy the wp-content folder, which is not the root of the site where the favicon lives. Any files at the root I have to manually SFTP in to change. I simply changed my local version, and there it sits, being all different.
Other trickery
- Just don’t have a local favicon so it shows the default logo thing for that browser. Different enough.
- A dynamic SVG file that shows the branch name (Whaaat?!)
- Chrome has an experimental “tab groups” feature. Have different tab groups for dev vs. prod.
- Use a browser extension to add title prefixes.
- Use a browser extension to automatically colorize favicons based on URL matches.
Speaking of favicons…
This has me wondering what best practices for favicons are in 2020, at least for garden variety content websites like this.
I hate to say it, but I don’t really care about what the icon is when someone adds this site to the home screen on an iPad, ya know? Aside from one fellow who wanted a copy of the whole database to use the site offline to teach prisoners, nobody has ever asked me about “installing” CSS-Tricks.
Nor do I care about the tile color on a Windows 8 tablet or to customize the color of the browser chrome on Android. That kinda stuff tends to be part of the process when “generating” favicons.
I do care that the favicon looks good on high-resolution displays (a 32×32 graphic isn’t much of a splurge). I like the idea of SVG favicons. I like the idea of making sure dark mode is handled. I like the idea of doing this with as little code and files as possible. Anyone dig into this lately and want to enlighten me?
- “Visual” difference. Hm. I wonder what could be done for developers with visual impairments? Ideas?
Having a browser plugin change tab labels might work, and adding a dev indicator to page titles as part of the dev build process woulddefinitely work, for us VI devs.
I’m really glad to discover it’s not just me that does that. ☺️
RealFaviconGenerator speaking! :)
Since a few weeks, RealFavicon shows how your favicon will look like on desktop browsers, including for dark mode. Plus, you can quickly add a background to your icon so your dark logo will look great in both light and dark modes. Good.
The incoming features:
– Make the SVG favicon part of the favicon package.
– Allow two different designs for light and dark modes.
Would that make a good solution for 2020’s favicons?
As a RealFaviconGenerator user, that sounds good to me.
Ha! This has happened to me. Made major changes and only realised hours later it was on the production site. It was a disaster.
I just use a different title… I add the ENVIRONMENT prefix so I see something like “Dev – MySite.com”. Even when the tabs are small I can still see the Dev prefix.
Assuming that developers are looking every now & then in the console tab of the browser developer pane, and assuming that people with visual impairments can manage the developer pane as well, you can add an automatic console message with a bit javascript. For instance, if you give the favicon an Id, something like:
if (location.href.indexOf("http") == -1 ) {document.getElementById("favicon").setAttribute("href", "technix/favicon-development.png");console.log("ATTENTION: this is the development site!");}
Then a locally stored page wil show the message. – In case the development site is also on a server elsewhere, then you’ll need instead of the “http” in the indexOf(“…”) some other identification (f.i. the map-name, subdomain etc.) of the production site.
“Then a locally stored page wil show the message” … and the different development favicon of course. :-)
If you have two instances open re the OP, you can’t easily see which is which…
It only takes two lines of script to change the title, why bother with an extension? I just check the URL doesn’t start with file
On WordPress sites as needed, I write a little CSS that targets the current URL, and depending on the URL it assigns a different background color to the WP admin bar… So staging.domain.com has blue, http://www.domain.com has red, SB.domain.com has grey etc. That CSS is part of the project so it works fine with git etc.