[wp-hackers] What's the best solution to develop a website in sandbox?

Andrew Gray andrew at graymerica.com
Sat Jul 16 14:57:39 UTC 2011


This is how we do it.

We set up three versions of the website online:

Development
Staging
Production

We then work on the development copy and and make sure we keep a punch list of all the DB changes.  These can be plugin settings, WP settings, pages/posts/etc added to WP, user level settings.  Basically anything that needs to configured or changed on the new version.

We work locally, FTP up changes to the development site as we work.  We keep all the local files in either dropbox or SVN depending on how big the client is and how many developers are working on it.

Once the site is approved by the client on development, we check everything into source control.

Then we test the deployment to the staging server, apply all the changes from the punch list.

If the changes to the staging site do not break anything, we wait till a slow time, or late at night, make the site "Members only" and deploy the changes to the live site, do everything on the punch list and hope we did not miss anything.

For the database, we just copy the live database to the staging and development servers and change the URL with an entry in WP config.  I normally avoid plugins that keep the URL in their data.   Since most sites have content that is altered by the client, we keep the images and upload paths pointed to the development server.  This way we do not need to move all their images to the development site.  We then go through and update the settings to point to development API Keys, FB apps, and other settings.

Personally, this whole process is one of the most annoying parts of using WP as the basis for websites.   The idea that all the urls are hardcoded all over the place in the db still boggles my mind, but I have heard it from the mouth (in person) from those in charge that this will never change.

We also develop custom apps in Code Ignighter, and I would never in a million years, hard code the URL of the deployment  into my DB.  We also have switches in the config that changes values based on if the site is in development or not.

In WP, things like the FB app id, email addresses, active plugins, and tons of stuff needs to be changed on a development version if you want to actually debug your website.

My opinion is, the lack of smooth, standardized deployment tools, is keeping WP from being a serious contender for an application development and enterprise software product.    Even Magento is easier to move, and that is saying something.

I am constantly trying to improve our process so we can have fewer surprises on deployments (since they happen late at night), and what works for me, may not work for you, but since this topic comes up on this list every month, it is obvious that the development -> staging -> production workflow is an issue.  

If I had my druthers, I would build some sort of versioning system built into to WP that allowed themes, plugins, and developers to register transformations that needed to happen in a new version.  Imagine if you could just increment the version number of your theme or installation and fire off the creation of new widgets, pages, menu items, etc from a standard set of scripts.  Then a unit test method to ensure your changes do not break something.  

Or, let me check in all my wp-options changes into source control and apply them when I commit.

If you build a site one time, on your local machine, and then launch it, it is no big deal, but if you are like us and have multiple developers working on sites for clients that want major changes constantly and have no tolerance for downtime, then it starts to be a pain.   

thanks for taking the time to read my whole post, or just skimming it,

Andrew Gray

www.tayloegray.com





>> 
>> 
>>> Since themes and plugins are portable, you can develop locally and upload to an online site for testing and demonstration. I actually version-controlled like that once by adding the version number to the theme folder and style.css and just leaving all of them on the testing site. Each shows up as a separate theme, so if you mess something up in the latest version it's nothing to revert to a previous theme and take the latest back to the workbench.
>>> 



More information about the wp-hackers mailing list