Stop Building Sites In Subfolders? I disagree.

Drew McLellan wrote an interesting article on March 9, 2011. Of course a year later, comments are closed (as they should be unless you want to get daily viagra offers) and I couldn’t add my thoughts, so I thought I would explain why I build sites in a subfolder on the live server.

Drew specifically talks about Perch. I’ve never worked with Perch or any CMS other than WordPress, so perhaps his article is spot on. But when developing WordPress sites, I favour developing in a subfolder on the client’s server.

If the client has an existing site, I create a new subfolder, set up a fresh installation of WordPress, including a database and start working there. I’m a big fan of the BackWPup plugin and set that up during development as well, that way there’s a backup of the theme and database if anything goes wrong.

When it’s time to go live, WordPress provides a simple step to give WordPress it’s own directory. No files but two need to be moved to the root directory and WordPress takes care of the urls. So there’s no danger or messing about with links and losing any page relationships.

By working on a temporary server, I’ve learned the hard way that no two servers are the same. Just last week, I proceeded to set up WordPress on a client’s hosting provider only to find out that they are running a lower version of PHP than required. I’m glad I found that out sooner rather than prior to launching. Now the client has time to look into new hosting.

Additionally, you might not believe this, but clients sometimes disappear and never provide copy. Gasp! Shocking I know. This happens to me at least once a year. I set up the site, make sure everything is ready to go, give the keys to the client and then wait until they tell me they are ready to go live and everything goes quiet. By having them on a subfolder on their live server, the ball is in the court and I don’t have to maintain a temporary site on my server.

I build on average 50 WordPress sites a year and this is my workflow. It makes sense when working with WordPress. What are your thoughts?

7 comments:

  1. I do the same thing for the same reason :) Unless I have to do MultiSite. Then I’ll move the extant site to a subfolder, put a static page that mimics their old page, and move from there. It’s a hassle, though.

  2. I always develop locally and then push to the dev server (sometimes client, sometimes mine) automatically with Beanstalk. I’m not opposed to developing in a sub-folder on a client site at all I’ve just found it faster to build locally as you no longer have to wait for the file to upload.

  3. Actually, I agree with both of you — evil, I know. What Drew is really saying is 1) Don’t develop in production, which I absolutely agree with; and 2) Don’t use a sub as a staging space with the intention of moving all the files afterwards — and there again, I agree. I don’t know Perch, but having done just that in my static HTML days, only to have to fix all the links by hand? Just no. Ick.

    But what you’re talking about with WordPress is giving WordPress its own folder as its permanent installation location, and there, I’m right with you. It’s handy on a fresh hosting account, but even more so when I get a client who already has a site and wants to move over to WordPress without moving hosts; I have one who came to me with the remnants of a static site, a Mambo install, 2 separate Joomla installs, 2-year-old WordPress files in the root folder (installed when they hit the one-click installer in their hosting account, and then never used)… you get the idea. We were able to get WP up and running in its own neatly-contained folder without any downtime for them, and then back up and clean out all the junk without having to worry that some random file might be needed after all.

    (After that one, I strongly advise starting fresh even if they think they don’t want to move.)

  4. I do a combination of the above.

    When I start the project, I look into the client’s hosting specs right away, if I’m not hosting on my dedicated server. If there are any issues (which has been rare) we start working on them right away.

    Meanwhile, I develop the theme locally with MAMP – very convenient not to have to keep FTP’ing, as Curtis says.

    When it’s ready to show the client for feedback, I upload to my dev server (subdomain.mydevsite.com).

    Only when I receive final payment from the client and the site is ready to go live, do I move the site to the production server, whether mine or theirs.

    I find having a dev copy of the site on my server very convenient and I keep it installed as long as they remain a client. That way if they come back for modifications down the road (which often happens) I can safely make the revisions first on the test server, rather than risk making functional/structural changes directly on the live site.

    This method has worked well for me over the years but we all work differently so I say we should all use the method that has proved effective for each of us!

  5. My setup is very similar to Curtis’. I do everything locally and version control it using git (sometime’s I’ll use svn if that’s what the client already has setup) and then I use beanstalk (http://beanstalkapp.com/) to automatically push my commits to the server.

    I’m currently experimenting with a slightly different set-up, using private Github repositories and using DeployHQ (http://www.deployhq.com/) to push the changes. I am starting to prefer this setup over Beanstalk because it allows me to work with public repositories as well as private ones, and overall prefer the interface and features of Github. That being said, this set-up (Github + DeployHQ) comes out more expensive over Beanstalk.

Comments are Closed.