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

[Daniel Westermann-Clark]

Long ago (probably around the WordPress 2.0 days) I wrote some scripts
to assist in maintaining WordPress setups like this:

https://github.com/ufwebadmin/WordPress-Maintenance

I recently updated them to support WordPress 3.x and multisite setups.

You can configure each target, like dev, test, and prod, with
information on where to deploy it and how to connect to the database.
Deploying is just a matter of typing "wp_deploy.pl -e dev".
Synchronizing the databases is just "wp_sync_database.pl -f prod -t
dev".

While the scripts don't handle updating attachment locations, they do
update the wp_options table with the appropriate siteurl and home
values.

If I had to start all over again, I would probably go the same route
as Adriaan with git and post-receive hooks.

On Sat, Jul 16, 2011 at 10:57 AM, Andrew Gray <andrew at graymerica.com> wrote:
> 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

-- 
Daniel Westermann-Clark