I a starting a project where 2 people will be developing a site on WordPress. It also may be necessary to have a development server setup where my client can view changes to the site before we push it live. There also may be database changes (like wordpress settings) that should be pushed all the way from development to dev to production.
I am wondering what the best workflow is for this. I understand the general concepts because I usually develop in Rails and therefore run migrations and use capistrano and git, but I would like to have the same tight workflow for a WordPress site. Any experienced WordPress developers out there?
Update: Maybe I did not make this clear enough but I understand wordpress. I have created 5-10 wordpress blogs and customized functionality. However, I have never worked on a wordpress site with multiple people or had to deal with having a dev, staging, and production environment.
Thank you!
To deal with this type of DEV and PRODUCTION environment, I’ve written a perl script to help me with what would otherwise be manual work. I’ve given certain steps familiar names so I remember to run them in the correct order. I only have DEV under SVN. I create a PRODUCTION environment each time with this script. That way I don’t have to worry about maintaining 2 branches of code.
I’m using SVN so I choose a new checkout directory (like /tmp/foobar) of my DEV code. It’s not going to be there very long.
Optional step 0: diff database structures
Sometimes plugins will add tables, and this will show that. Otherwise I replay the changes made within tables (install a plugin) when it’s not worth it to diff certain tables and copy SQL statements.
step 1 clean:
The script deletes all files in the current directory, do a fresh svn checkout of the DEV branch. This fresh checkout is going to be transformed into the PRODUCTION code and copied to its webroot.
step 2 make:
perl runs a vim search and replace of the database name in wpconfig.php. The search and replace is just as easily done in perl.
Remove local file uploads directory (so we don’t overwrite the PRODUCTION one). wpcontent/uploads I believe it is on a standard install.
Another find and replace on all text files within the project that have my DEV url, for example
step 3 install.
Backup the wpcontent/uploads with dircopy() to be safe. Do a dircopy() of this cleaned up directory to the PRODUCTION webroot. Remove all .svn directories within the webroot like so:
Now your DEV code has been transformed into your PRODUCTION code replacing all hardcoded URLs and keeping safe around the uploads directory that is not in SVN. You can even have it stop and start apache for you too. I hope my solution helps solves your problem.
Workflow huh? Well I worked with a couple of people on complex WordPress websites and still do. We use Subversion and Trac most of the time and it rarely comes to making some changes in the database. Only during setup I guess.
Here’s the script:
It’s way too simple, I know, but that’s the way I like it 😉 Don’t forget to replace PASSWORD with your password and pehaps you wouldn’t like to use the user root for these purposes (I don’t really care though, that’s why I do).
Save the file into
copydb.sh
for example, then chmod +x copydb.sh and then you can run it like this:./copydb.sh database1 database2
😉WordPress tends to be quite modular; I think a source control will help, and perhaps write a script to automate the uploading to a preview site. You can keep one folder which is only updated by SVN, and one working folder.
WordPress is modular in a sense that it can use Page Templates and Widgets, as well as plugins. You can write pieces of your site as widgets and plugins, and put them together to make it work. For pages with custom layout or PHP code, you can use Page Templates. You rarely need to touch the WordPress core files (nor should anyone), so if you stick to the extension tools given by WordPress, it would be fine.
You might want to try Role Manager plugin for permissions management and Turnkey WordPress for quick wp install in virtual machine. Don’t have a clue about something that could have git-like role, though.