Graphics Programs Reference
In-Depth Information
6. Go back to make sure the upload is i nished and successful.
7. Reload again. Still nothing.
8. Try sprinkling in !important . Upload, reload, nothing.
9. Start swearing at your computer.
10. Check Firebug to see what's overriding your new styles. Discover they aren't being
applied at all.
11. Continue in that vein for several minutes before realizing you were selecting Reload
while looking at the live production server, not the staging server.
12. Go to the staging server and see all your changes.
13. Start swearing at your own idiocy.
It's happened to me more times than I'd like to admit. h e last time it did, I realized that if I
could just serve up a special extra stylesheet from my staging server, one that made it obvious
I was on the staging server without blowing away the whole design, I'd save myself a lot of
html { background : url(staging-bg.png) 100% 50% repeat-y ;}
As it turns out, you can do this in a variety of ways. h e most elegant is to use HTTP headers
to send out an extra stylesheet. If your Web site runs on Apache, you can do this by adding
the following line to your server's root .htaccess i le:
Header add Link "</ staging.css> ; rel=stylesheet;type=text / css"
Now all you need is staging.css to sit at the root level of your development server, and
you're golden. You aren't limited to that placement, either: You can put staging.css
anywhere on the server and just modify the bracketed URL to match its new home. You can
also use a fully qualii ed URL, like , if you prefer.
Just make sure you keep the angle brackets, because they're required.
Of course, there's always the risk that you might migrate both staging.css and the
.htaccess i le to the production server. You can avoid that by not using .htaccess to
serve up staging.css , but instead send it via an addition to httpd.conf . It would look
like this:
< Directory / path / to / website / rootlevel>
Header add Link "</ staging.css> ; rel=stylesheet;type=text / css"
</ Directory>
Again, you'd alter /path/to/website/rootlevel to match your local install. It's just the
UNIX i le system path to the directory where your Web site lives. h e advantage here is that
you're a lot less likely to have httpd.conf copied from one server to another. It isn't
impossible that it would happen, but it's mighty close.
Search WWH ::

Custom Search