Hot answers tagged

92

@Insanity5902: Deployment of a WordPress site from one box to another has been a PITA since day one I started working with WordPress. (Truth-be-told it was a PITA with Drupal for 2 years before I started with WordPress so the problem is certainly not exclusively with WordPress.) It bothered me that every time I needed to move a site I'd have to spend so ...


43

I use git for this and find it works really well. A few suggestions: Add your uploads directory (wp-content/uploads) directory to your .gitignore file. Run a web server and database server on your development system so you can test changes locally before pushing them to production. Keep your database connection settings consistent beween dev and prod, or ...


28

When possible, I set WP_HOME and WP_SITEURL in wp-config.php. This, combined with a database dump and import, is the most simple of all solutions I'm familiar with. http://codex.wordpress.org/Changing_The_Site_URL#Edit_wp-config.php


20

I have a setup I'm pretty proud of, and it works extremely well for my team. General Structure I keep the entire installation under git. All changes, be it a system update, adding/updating a plugin, adding/updating a theme, go through the same workflow. Changes can be rolled back at a moment's notice. I have a deployment server (an old P4 desktop) running ...


19

I would highly recommend setting up Capistrano - it's a little bit of upfront work the first time, but after that you can easily use it for new setups. The main advantages are being able to deploy from your desktop. It may not sound like much, but ssh-ing into the your remote server, and doing a git pull is still a pain in the ass. easy rollback to a ...


18

My favourite hack; add a setting to your /etc/hosts to make the production domain point to your development box, just on your machine. To deploy to production you rsync all the files and push the database over. The risks of this strategy are clear; you might confuse your development environment with your production environment. It still an easy fix ...


8

I wanted something similar when I migrated to WP a few months back, so I wrote a pretty simple shell script that uses rsync and mysqldump over ssh: http://snarfed.org/sync_wordpress It's not sophisticated or web based, but I'm happy with it.


7

WP Engine is a new service that offers "One-Click Staging": WPEngine has an exclusive feature called “staging.” Here’s how it works: Before you make a scary change to your blog, click the “snapshot” button. We make a complete copy of your blog and set it up in a separate, safe area. You can play with anything you want; nothing’s live. Only when you’re ...


6

I actually did a WordCamp presentation on this topic. Rather than repeat myself, here's a screencast of it and here's a very simple deployment script to accompany what I discussed. In short, I use GitHub to host the repo, and use a webhook to deploy changes based on the git ref. This allows you to use Vincent Driessen's git branching model and opens you up ...


6

I'm one of the developers of WP Migrate DB Pro, and would like to answer @Ennui's question: "Do you know if the db url replace script it runs takes into account serialized strings?" Yes, it does handle serialized data. In fact, that is the primary reason I developed the free version of the plugin back in 2009. :) Unfortunately I only have a reputation of ...


6

Set the constant DISALLOW_FILE_MODS to TRUE in your wp-config.php: const DISALLOW_FILE_MODS = TRUE; See the Codex for background information: Setting this constant also disables the Plugin and Theme editor (i.e. you don't need to set DISALLOW_FILE_MODS and DISALLOW_FILE_EDIT, as on its own DISALLOW_FILE_MODS will have the same effect). It will also ...


5

I have been working on a simple and pluggable command line interface. The basic work is done but we now need to start writing more commands (and implement it in plugins). Please feel free to fork and contribute! You can find the code on Github.


5

Duplicator Plugin: Here is a plugin that I have been working on. It's currently in beta but it gets the job done for most sites. Right now it is targeted at smaller WordPress installs. http://wordpress.org/extend/plugins/duplicator/ Resources: Additional resources for the plugin can be found here: http://lifeinthegrid.com/duplicator/ Community: Please ...


5

You might take a look at a product from iThemes, called BackUpBuddy. I've only used it twice, each time had a hitch or two, but overall it looks promising.


5

Externals, definitely. Set up your own SVN repo, then make WP as an external in the repo. I put it into a /wp directory. You can access the WP SVN as an external here: http://core.svn.wordpress.org/ I tend to use trunk. You can use a branch, if you really, really want. Branches get auto updated with minor releases (/branches/3.0 held 3.0, then 3.0.1, 3.0.2, ...


5

I know this question is a little older however as I've not seen this as answer here, I'd like to share what I normally do for single-site git based setups and deployments and it's working really well, also with working from multiple devices, locations and with multiple developers (all having their own local repos they operate in as it is common for git). I ...


5

I would be very afraid to develop on 3.8.1 and try to run the same code on 3.5.1. Things have changed. 3.5.1 is ancient by web app standards. I can't say that I have ever tried to "backport" like that, but it does worry me. Much of your code would work. WordPress itself is pathologically backwards compatible, but if your code uses new features (intentionally ...


4

I am personally addressing this issue with my project on Github, called Autopress. I don't have a perfect solution yet, but I'm getting closer, especially with the wpstage plugin from the wpengine folks.


4

This looks promising. We are working on some scripts to handle migrating some of the data, wp-options for example, changing paths in the db, a copying over media. The issue I have is that the live site continues to grow while the other is in development. One site we work on has 20 posts a day and over 3,000 comments per day. That is too much data to ...


4

First, I think its important to consider what you are going to Version Control . I would recommend against putting the entire WP directory under VC. I think it makes the most sense to put wp-content/themes/YourThemeName under VC. For a large site with a high number of complex plugins I could see the case to including wp-content/plugins as well. If you ...


4

I am borderline on voting to close this as "not constructive" as it seems to be the kind of thing that will solicit debate and opinion rather than answers. But... That is not what my work flow looks like, and it makes my approach (and answer) different from most of the rest of the answers so far. Install WordPress locally This is cloned from a local ...


4

I commit all WordPress because I consider it one big ball of code that pertains to one site, this means updates to core WordPress files, plugins and themes are all part of the commit history. I don't use sub-modules or any other weird nested revision setups. If you have a complicated structure of including multiple repos, I suggest keeping them separate and ...


3

I recommend handling the 301 redirect in your web server rather than in WordPress. mod_rewrite or RedirectMatch will be much more efficient than spinning up WordPress to deliver a Location: header. <VirtualHost *:80> ServerName busted-cheap-url.com # mod_alias RedirectMatch permanent (.*) http://great-new-url.com$1 # OR mod_rewrite ...


3

Hi @Chris Adams: I just ran across these WordPress Mass Management Tools which are not the same as drush but are the closest thing I seen thus far.


3

Two Google Summer of Code projects that have a similar goal: Automatic Migration (GSoC 2010) WordPress Move (proposal) (GSoC 2011)


3

As @andreascreten, wp-cli will do the job for you. wp-cli includes commands for W3TC (located in the src/php/wp-cli/commands/community/total-cache.php file), so you can flush the cache by running: $ wp total-cache flush <type> Where <type> is one of 'db', 'minify', 'object', 'page' or 'post'. (Note: If you use 'post', you'll need to pass in -...


3

I always develop the webiste locally on my machine with the setup mydomain.dev and using svn or git to save versions of the code. The next step is to put it on a test domain like stage.mydomain.com and after that mydomain.com I use this to change the url:s in the database: https://interconnectit.com/products/search-and-replace-for-wordpress-databases/ Its ...


3

If you have databases reachable from the outside ie: mysql1.example.com you can work on a local development environment connected to that the whole time. I just found a nice thing to put in wp-config.php to be able to change the host depending on your environment $host = $_SERVER['HTTP_HOST']; define( 'WP_HOME', 'http://' . $host ); define( 'WP_SITEURL', '...


2

Normally I login to phpMyadmin upload the database and edit the contents of wp_options>siteurl and wp_options>home to the expected domain. If you need to update URLs within your posts and pages content you can do a search/replace for the URL and the media/uploads path on the .SQL file prior to uploading. It's a quick job.


2

I use subversion's export command to install the WordPress files (http://core.svn.wordpress.org/tags//) as well as all plugins in the repository (http://plugins.svn.wordpress.org//tags//), then just zip the theme and custom plugins and install them normally. Once all of that is up and running without content, I export the test DB and do a search/replace for ...



Only top voted, non community-wiki answers of a minimum length are eligible