Long time member, somewhat lacking contributor here.
I’d like to take some time to discuss the development of a workflow for building Wordpress websites. For pretty much all of my commercial time developing websites I have used mostly static html to develop Dreamweaver templates which our clients were able to update using Contribute. Occasionally I’d write some snippets of PHP where I needed any extra bit of functionality.
However myself and a colleague have been dabbling with Wordpress for the last few months and have decided to draw a line under the old style of static site that we had been building in favour of buildings sites using Wordpress as a CMS. We actually plan on dropping Dreamweaver completely from our workflow as we’ve found ourselves living in the code view of that in our experiments with Wordpress and so I see no need to pay the huge asking price for a piece of software we no longer need. (Komodo Edit seems to be working out fine as an alternative).
I guess I’m a little nervous about making the move to developing these new sites in Wordpress since we had our old workflow down to a fine art in terms of the complete development cycle of a project. Now with Wordpress I am trying to come up with a workflow that works and wanted to see what the community at Sitepoint did in relation to this and to get feedback on how I think we might do it.
Here’s my proposed workflow leaving out elements such as discovery, spec work, design, testing, etc - really just interested in the build process and deploy process here.
Each of us has a local copy of Wordpress running. We would have some dummy data here and would use this to develop the initial template for the project along with any functionality or plug ins that need to be created.
When the template is finished we create a fresh Wordpress installation in a development server that is accessible by the client. This development server is identical in every way to the final live server where the website will eventually be deployed. We upload the template to this server and begin to develop the structure of the website as per our discovery and spec work. We allow the client access to this server so that they can see how their project is developing and can offer feedback if required (keeping in mind that we make a point of not going back on our milestones in the project unless we have to meaning any feedback may not be relevant).
When this development version of the website is complete we install a fresh copy of Wordpress on the live server under that clients directory. We export all of the data from the development server to the live site and amend the url entries in the options table of Wordpress.
That’s it!
When it comes to creating the development version of the Wordpress website are there any things that I should NOT do that should be done on the live version? Would there be settings that I might set on the live server as part of the installation that might be overwritten when the development data is uploaded? One thing that springs to mind is when I am asked about making the site viewable by Google. I’d imagine that I’d set this to no on the develoment installation but would want this then amended for the live site.
One thing that stands out to me about this process is the constant need to install fresh copies of Wordpress at various stages. I’m wondering if this is the most efficient method to develop these websites?
Also having several live Wordpress sites (we average one website a month with our current work output) will mean that they will need to be kept up to date with the latest version of Wordpress. I’m just wondering what is the best way to do this short of logging into each site individually and updating them? I know that we can use one database for all of the different Wordpress sites but in my eyes this would still involve having to update each site individually anyway.
I know that this is quite a long post and it asks alot of questions but I don’t want people to think that I just came on here to to make you guys tell me the answers that I need. I have researched this as best I can and have found some articles and blog posts dealing with the matter of a Wordpress development workflow but they don’t always answer the questions that I have. Whatever happens it’s going to be trial and error for us and in the end we will work out our workflow but I’m still curious to hear from the Sitepoint community and also it’d be interesting to read about your own processes in relation to this.
So, thanks for reading and I look forward to discussing things in more detail further along.
I found your post looking for information about an idea WP workflow when there are two people working on the same site.
At the moment, I use DropBox to share my WP theme & plugin folders (they get symlinked into the shared folders from the WP directory), and we are starting to use a SQLdump to keep the WP dev databases the same.
It still doesn’t feel like there is a perfect continuity between dev, test and live. I’d be interested to know where you’ve got to in the last few months.
I’m not familiar with wpmu, but now I might have to check it out.
If I was you, I’d actually invest in a really good framework theme, and spend the time developing a standardized child theme based on it. Or just personalize the frame if you’re allowed, just to avoid those irritating random upgrade warnings.
You can override templates, define your own functions, have your own CSS. This will greatly reduce your upgrading troubles (but no matter what you do, upgrades are scary as hell, and they will have to happen).
If you write your own plugins, create your own widgets and widgetable areas and always work off one incredibly flexible frame you will develop a relationship with the frameworks’ company - they will give you heads up about potential issues well before hand.
Personalizing plugins and widgets
hugely increases the flexibility of your (child) theme
allows you to become exceptionally comfortable with the API
if you are going to run them all off one db and server, the notorious inefficiency of plugins not working as directly together as they can, needs to be avoided. You’re going to be making a lot of queries to one DB and placing stresses on that one server. As those sites grow, efficiency will become even more tantamount!
Know the schema, know the API, learn to use it as a CMS that just happens to be called WordPress by the masses and you’ll be back to having it down to science in no time (with a huge base of developers you can leverage the knowledge of no less!)
I’ve written a few WordPress plugins, and every version release requires that I look into what’s changed. I almost dread the upcoming 3.0 major version release.
So if you’re providing ongoing maintenance I’d think about it a lot.
That said, if the client is going to assume control, they may install any number of plugins that may or may not be compatible with your work. Are you running the sites under WPmu?
If so, then you can control the plugin issue, if not, put some kind of clause in your contract.
As for version upgrading, the newer versions all have “one click auto upgrade” so the clients can upgrade easy enough. It’s just compatability issues you need to consider. And there’s no way of knowing ahead of time what they might be unless you try the pre-release beta versions ahead of time.
Thanks for replying. With these new WP sites that we plan on developing our main aim is to give the client as much control over the content of the site as possible, which is more so than the current setup allows.
Our intention is that the client will have control over the content and the ability to create new pages but I wouldn’t want them to be able to install plug-ins our update the website themselves. I’d plan on disabling this functionality for their log in. At least this would be our default setup (stated in the contract) and should a client have a little more experience and wish to make use of these things then we’d turn them on after they sign a liability waiver.
Maintenance will be one of the key things for us so I don’t have a problem with updating the sites. I was just looking to see if there was an easier way to do this. I’m sure that I can work out a system wherein we can take a morning to update all the WP sites one after the other.
You mentioned the compatibility issue which I hadn’t considered. I guess what we’d do would be to install these upgrades on our development servers to ensure that there are no issues before deploying to a live server. Also since we’d have development versions of all of our clients’ websites we’d be able to test each one in turn before updating the live site.
Based on my experience with our client base I definitely don’t want to give them the option to update to new WP versions themselves. When things go wrong they will pick up the phone and hold us entirely responsible!
You also mentioned WPmu and to be honest I’m in two minds whether to go down this route or not. I’m curious to know if people use this and what the pros and cons are based on experience. I’m especially keen to know how people handle the issue of multiple domains. For example ensuring that www.clientsite.com points to the correct directory within the installation.
I’ve not used WPmu except on localhost for testing. AFAIK the sites are physically sub-domains, but through server trickery and DNS mapping they are virtually their own domains.
All the sites work off the one version of WPmu, and the “master” account controls the plugins (and themes too), both those that are used site-wide and those that are available for possible use by individual sites.
So it would make control of incompatabilty and upgrading easier. But it would mean you’re hosting other sites on your server.
Perhaps WPMU is the solution for me then. We host all of our websites within the one shared hosting platform and in essence they all live under the one master directory. Each of the websites would live in its own folder and they could run off the one database.
My gut is telling me to go with individual wordpress installs for the first few sites as a starting off point before delving into the larger overhead of the wpmu solution - which should in time reduce that overall overhead!
Thanks for your feedback again Mittineague. I’m still curious to hear how others have approached this but am beginning to get a feel for what we will do at least in the early days.
