All in the <head>

– Ponderings & code by Drew McLellan –

– Live from The Internets since 2003 –

About

Stop Building Sites In Subfolders

9 March 2011

I’ve found out a lot about other people’s development practises whilst building and supporting Perch. One thing I never expected to see, and genuinely surprised me, was to find that not only are people actively building sites by working live on production servers, but they’re frequently developing new sites in a subfolder of an existing live site. This must stop.

Don’t develop on live servers

I really shouldn’t need to say this, but working directly on live server is a bad idea. Despite the fact that any mistake you make (and let’s not pretend we don’t all make them) could affect the functioning of live websites, it means you’re not making proper use of version control systems. If you screw up and need to go back to a known working copy, you can’t. If you accidentally delete the wrong thing, it’s gone. Couple in the fact that you’re working live means that any mistake is not just an annoying loss of work, but could result in loss of business for your client.

Don’t build a new site in a subfolder

I couldn’t quite believe how prevalent this way of working seems to be. It’s a terrible idea to develop a new site in a subfolder of an existing site, with the intention of then putting it live by moving all the files up one level.

Why is this so bad? Web pages are all about relationships. The relationship between pages (it’s a hypertext system!) and the relationship between a page and its various resources such as images, stylesheets and so on. These are expressed as links and resource paths in your pages. Once you’ve developed and tested your new site and are ready to go live, the thing you should avoid doing at all costs is to shift the pages around your site, possibly breaking all those links. Why go through the trouble of testing at all, if you’re about to make such a monumental change that will require retesting again. On a now-live site. It’s crazy. Stop doing it.

Here’s what to do instead

Here’s the most basic workflow you should be adhering to. You can get a lot more complex, but this is a minimum.

Firstly, if your site will ultimately be at the top level of a domain (as most typically are) that’s how you should develop. Set up a local web server (either a dedicated physical server, a virtual machine, or simply something like MAMP Pro or XAMPP) and build your site as an independent website on that server.

Use source control. Be that subversion, git, even CVS – whatever works best for you, but use something. Find which systems your existing editor has support for and start there. Use a hosted service like Beanstalk if you prefer. Commit your changes regularly.

When you’re ready to share the site with the client or other team members, deploy it to a proper site of its own. Not to a subfolder. This could be a subdomain of the existing site like newsite.client.com or you could keep it under your own control with something like client.mycompanytestsites.com. This is a great use for one of those cheap reseller hosting accounts. The important thing is that it’s in a proper site of its own, just as it will be when the site is put live.

The above will cost very little in terms of out actual outlay, but will save you time in the long run, as well as making your development processes far more robust and professional.

- Drew McLellan

Comments

  1. § candi:

    Great advice. I plan to go freelance and will have to do everything on my on versus how work would have me do it.

  2. § Nick Thorley:

    I couldnt agree more Drew. I used to do that also which works fine for static websites but once you move onto using a cms then it can be disastrous. When you create content and include links to pages and other resources they often create links which would break if the site was moved to another directory.

    I think most of this practice comes about from people having cheap hosting where you cant create new sites or subdomain based new sites.

  3. § Jon Hicks:

    Where do you host the subdomain? If not in a subfolder of the site, then would you use a separate hosting account?

  4. § Arno:

    a very good point. however, these are facts I had to learn and self-educate myself about over years of practice and work. and still, for some projects I completely omit version control, just because they’re small.
    I believe that you’re frustrated, because through perch you get to know people, who don’t adhere to your standards, either because they don’t know any better, or because they simply don’t care. either way, perch is advertised not only as a little CMS, but also as simple and easy to understand and implement. this attracts people, that have only recently started to create websites, I imagine. of course they can’t know any better; they are beginners! I like your post because you don’t whine, but offer a better solution as well.
    still, you can’t be angry because not everybody is as smart and has as much experience. if the project is too complex, perch probably isn’t the best choice. some may choose it because they enjoy the way it works, but many probably choose it because it is simple. and they have this sort of simple problems. it’s not even their fault. they just don’t know.
    I believe you are going in the right direction with the perch documentation: educating people about webdesign and best practice, even beyond what is required to set up perch. thank you.

  5. § Arno:

    @Jon: I usually map the live domain to one folder, the subdomain to a folder on the same level. next to each other. that way, I don’t know how they would interfere with each other.

  6. § Drew McLellan:

    Where do you host the subdomain?

    I guess that depends on your hosting setup.

    I believe that you’re frustrated

    I’m not frustrated or angry!

  7. § David Rodriguez:

    Very nice and concise points, thanks for the tips. I’ve been testing early static versions of sites and webpages on subfolders for a while because it was an easy, convenient and no-cost solution (or in web-marketing jargon b.s. “FAST, EASY, FREE”). I can see why it’s not a good idea though.

    Lately I started using dropbox to pass files to myself on other computers. Now I have access to the files from any computer without junking up any servers hosting live websites.

  8. § Arno:

    I didn’t mean to offend, I just figured I would be frustrated, if I had to deal with the same kind of problems all the time.

  9. § Brad Touesnard:

    Great post Drew. Another important point is to add a robots.txt or password protect newsite.client.com so it doesn’t end up in search engines. This would be a disaster because not only are people visiting your unfinished site but I believe if you have the same content as your live site, it could hurt your Google Rank.

  10. § Dave Ellis:

    I guess as you’re supporting Perch users, you’re seeing what is probably a large proportion of that user base that wouldn’t really consider themselves to be developers (much like myself) and they way they’re building sites. That’s probably testament to the product itself, in that you don’t need to be a developer to work with it.

  11. § ChrisArchitect:

    Kind of a funny post — funny in that I can picture the hairs on your back rising as you discovered these crazy things going on. Come on people

  12. § John Robinson:

    @Jon Where do you host the subdomain? If not in a subfolder of the site, then would you use a separate hosting account?

    The subdomain can be hosted wherever you like, but it needs stressing that there’s a massive difference between a site hosted at mysite.com/new with one hosted at new.mysite.com, with the subdomain pointing at the /new/ subdirectory (even though both sites are in the exact same location directory-wise). I don’t think Drew’s saying don’t actually have the files in that subdirectory, but make sure that relationships are kept intact between a live and dev environment. The realtionship between your file’s current location and site root is totally different between mysite.com/new and www.mysite.com, but a switch from new.mysite.com to www.mysite.com is pretty trivial.

  13. § Elliot:

    Version control? I’ve got Time Machine :-)

    Seriously, what’s the best solution when developing – on your own server or the live server?
    I always prefer to work on the actual final server as all those incompatibilities rear their head during the project not right at the end.

    If you set-up a sub-domain, how will this effect the ‘live’ site?

  14. § Barry Corrigan :

    I’ve had to learn this the hard way but the support from perch is one of the best I’ve ever seen the support you get from Drew is top notch.

  15. § Rachel Andrew:

    @Elliot you shouldn’t encounter major incompatibilities if you establish what your baseline server requirements are from the outset and make sure those exist on both the live and staging environments. So for Perch that’s PHP5 (any version) plus MySQL with some basic things enabled like sessions, GD or ImageMagick. Deciding what your development baseline is, is good practice. It means you can confidently say to your client what they will need on their server and not have any embarrassing issues on go live, and you can set up your dev and staging environments to closely mirror that.

    Using VMs locally is one way to have multiple dev environments set up if you have projects that have very different requirements.

  16. § Joseph R B Taylor:

    Hi Drew – I’m guilty of a few, proud to do a few others.

    My workflow: develop locally on Coda and I use SVN which connects to beanstalk for my repo. I only have regular MAMP so it’s not like my production server so I eventually have to post the unfinished (to some degree) work to the live server for testing. Usually that only consists of .htaccess stuff I can’t do locally.

    In order to match my production environment I have to set up a local Debian Linux server. Looking forward to it!

  17. § Justin Campbell:

    FYI this is how all Ruby on Rails development is done. It includes it’s own web server, uses a flat file database (SQLite) for development, has separate environments for development, production, and testing so you don’t mess with production data, and for the most part your site will behave exactly the same way on your development computer as it does on your web server (no messing with differing PHP builds or ini files to enable modules). It also pushes the developer toward version control, because most Gems (plugins) get downloaded as git repos, and many Rails hosts (Heroku) only allow you to deploy your code via git.

  18. § Matt:

    Informative article, but I’m still unsure about a couple of things.

    In order to give the test site a subdomain, doesn’t it have to be in a subfolder?

    E.g, I use cPanel so I normally create a folder called ’0-dev’ (preceding ‘0’ so that it appears at the top of the folder list, I prefer it that way) then create a subdomain such as dev.example.co.uk and point it to that subfolder.

    I normally create a new FTP account too, so that I don’t accidentally start working on the live site instead.

    However I imagine this conflicts with your advice in this article, should I be hosting the test site somewhere else? Maybe by creating a new account within WHM and uploading the files there? As I have a reseller account with my hosting company.

Photographs

Work With Me

edgeofmyseat.com logo

At edgeofmyseat.com we build custom content management systems, ecommerce solutions and develop web apps.

Follow me

Affiliation

  • Web Standards Project
  • Britpack
  • 24 ways

I made

Perch - a really little cms

About Drew McLellan

Photo of Drew McLellan

Drew McLellan (@drewm) has been hacking on the web since around 1996 following an unfortunate incident with a margarine tub. Since then he’s spread himself between both front- and back-end development projects, and now is Director and Senior Web Developer at edgeofmyseat.com in Maidenhead, UK (GEO: 51.5217, -0.7177). Prior to this, Drew was a Web Developer for Yahoo!, and before that primarily worked as a technical lead within design and branding agencies for clients such as Nissan, Goodyear Dunlop, Siemens/Bosch, Cadburys, ICI Dulux and Virgin.net. Somewhere along the way, Drew managed to get himself embroiled with Dreamweaver and was made an early Macromedia Evangelist for that product. This lead to book deals, public appearances, fame, glory, and his eventual downfall.

Picking himself up again, Drew is now a strong advocate for best practises, and stood as Group Lead for The Web Standards Project 2006-08. He has had articles published by A List Apart, Adobe, and O’Reilly Media’s XML.com, mostly due to mistaken identity. Drew is a proponent of the lower-case semantic web, and is currently expending energies in the direction of the microformats movement, with particular interests in making parsers an off-the-shelf commodity and developing simple UI conventions. He writes here at all in the head and, with a little help from his friends, at 24 ways.