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 ...
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 ...
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 ...
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 ...
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 ...
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 bare ...
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 ...
As of 2017 here are the two best ways I've found to handle the transfer of a WordPress database from development to production.
WP Migrate DB Pro / WP Sync DB
These WordPress plugins let you push, pull, and sync database tables between WordPress installations. This is much better than a find/replace for many ...
I fixed this by running this command:
sudo chown -Rv www-data:www-data *
Changed ownership back to www-data instead of root. This article helped me:
The easy way; use the WP CLI (also available as wp-cli.phar) to get a solid, maintainable solution for this requirement. More for this topic you will find at the command
wp plugin <command>
If you will need a custom script is is necessary to load the WP API, via wp-load.php and look for the function activate_plugin($path_to_the_plugin)...
The WP-CLI http://wp-cli.org initiated by andreascreten and now maintained by scribu is the closest thing. Its core functions are limited, but it's easily extended with custom commands.
The core functions should cover needs you describe, controlling plugins and settings.
As a side note: I recently used wp-cli to set up 2.000 product attributes with ...
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 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 ...
The reliable two–way sync is simply not something that have happened in WordPress.
The typical way is in line with what you are doing — pulling a copy of production database into development environment. Note that this is commonly the one direction it goes. It's much more problematic to try sync development back to production.
As far as plugin ...
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', '...
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 --...
While there's no shortage of good solutions here, in the spirit of sharing I thought I would add my bash deploy script to the pile: https://github.com/jplew/SyncDB
SyncDB is bash deploy script meant to take the tedium out of synchronizing
local and remote versions of a Wordpress site. It allows developers working in
a local environment (eg. MAMP) to ...
I've been using http://wordpress.org/plugins/wp-clone-by-wp-academy/. It works nicely!
Just 3 steps:
Install the plugin on both sites.
Use the plugin to generate a backup on the old site.
Take the backup URL it gives you and plug it into the plugin page on the new site, hit go, and your migration is complete in just a few seconds!
It adjusts all the ...
The answer is to try and avoid relaying on configuration changes via the admin interface. Don't use plugins that you can not configure by filtering options, or better, use only those that have an official API and use the API.
For example if a plugin has an option "pl_option" with which you are happy when its value is 5, do not change the option in the DB ...
Daniel Bachhuber gave a presentation at WordCamp Seattle 2012 called WordPress at the Command Line – An Introduction to wpshell and wp-cli. The presentation notes are available on his website, and the video should be on WordPress.tv soon.
/ - The root WordPress directory: all files should be writable only by your user account, except .htaccess if you want WordPress to automatically generate rewrite rules for you.
/wp-admin/ - The WordPress administration area: all files should be writable only by your user account.
While I agree with Justin Tadlock on a lot of things, I strongly disagree with him on this.
The reason parent/child themes exist is that there's a lot of common functionality used across websites. Instead of re-inventing the wheel every time, it's better to build from a solid base that has been tested by hundreds of developers and used on tens of thousands ...
Take a look at the bedrock stack. It uses composer to manage the version of Wordpress and third party plugins, and also includes capistrano for deploys, and vagrant / ansible for setting up servers including local virtual servers for development.
I recently did a lot of testing regarding this and here is the workflow I use, which does pretty much what you're asking for:
I use wp-cli to manage the wordpress core and update wordpress.
I use composer along with http://wpackagist.org to manage plugin and theme dependencies.
I use git and put core wp files in the .gitignore. So mostly wp-config.php and ...
I haven't tried this myself (yet), but it claims to deploy everything -- DB included.
There is also a tutorial to go with it:
Tutorial part 1
There is also a plugin named Adminize that will allow you to completely customize what the client can see in the admin.
If you use this plugin you can set yourself up as Admin and then give your client a lesser role, which will allow you to continue to have administrative control over the site.
As mentioned in my comment, ensure you test the following in a "clean" browser:
Set siteurl & home to http://www.example.com/wordpress-subdirectory
Set permalink_structure to nothing
Set active_plugins to nothing
Ensure there are no WP_SITEURL or WP_HOME constants defined in your wp-config.php
Remove all rewrite rules to do with WordPress from your ....
Couple different things going on here, but my two cents:
1) Philosophically: if a file may be modified somehow in any of its remote deployment contexts, don't keep it in the repo. Since W3TC keeps its settings in a flat file (and that flat file is updated every time you go into the W3TC settings screen in any context and hit "save"), it's difficult to ...
When exporting from original database you should choose to create the tables if they dosn't exist (First error). If you didn't choose that option (in phpMyAdmin that option exists, not sure in other database tools), the import file can not create the tables for your and you need to create then prior to start importing it.
For second and third error, you ...
I've also posted this question on discourse and @fullyint has answered it in detail. So I'm just posting a link for the answer and some excerpt
Helping Ansible and ssh to find the necessary private key
This means that you are manually specifying the private key with each ssh command, and yes, the corollary of manually specifying the private key with ...