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

[Lox]

I personnaly dump the database of the dev website to the production one and
I then run the searchreplacedb.php script from here:
http://interconnectit.com/124/search-and-replace-for-wordpress-databases/

2011/7/20 Daniel Westermann-Clark <danieltwc at gmail.com>

> 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
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers
>



-- 
Lox
lox.dev at knc.nc