I’d like to get some opinions and best practices on making major revisions to the templates, structure, and look of a site - when that site is already deployed and being updated daily.
Take the case of an ecommerce site with a couple of blogs. Orders are placed every hour of the day; products come and go; prices change; the blogs get updated. Now suppose that you are contracted to give this site a good redesign, one that will involve changing much more than just the CSS. New templates are needed, content will be added, and existing content will be moved around.
Obviously systems are different, but assuming the site is based on a popular CMS such as Joomla, Wordpress, or MODx, what general approach would you take? (If you want to delineate an approach for your CMS of choice, that’s great - particularly if it’s MODx :))
Shutting down the site for two weeks while the work is done doesn’t seem like much of an option.
If you do a differential sync when the new site is ready (presuming you have a way to do that across two different databases) you run the risk of either deleting the current information on the production site, or losing some of the new information in the shuffle.
Rolling out the new templates and content manually doesn’t even sound easy, and would probably result in some disruption of the production site.
This is why I’m comparing the problem to a logistical impossibility - changing the tablecloth while dinner is in progress, without unduly bothering any of the guests - yet there must be some way to perform what is surely a common operation in the world of web design.
I would probably develop this is on a local clone of the code and then push the changes to the live host when everything is done. Or at least clone it to a subdomain (like dev.mysite.com) and make changes there.
When the final version is done (and thoroughly tested) I would put the current website offline for a small amount of time (as longs as it takes, ideally this should be less than half an hour) to make sure it’s impossible for the database to change while I’m pushing the new changes. Before I’d push any changes I’d make a complete backup of the live database to make sure that if anything goes wrong, I can always just revert (ctrl+z, ctrl+z, aaaah!)
Make sure that if you take the website offline you plan this well ahead (like say a week beforehand) and put a notice on the website indicating that the site will be offline for a short while, so regular visitors know it and won’t be surprised.
Even though the taking offline method is not the most ideal one, it is the least stressful for you as a developer, and in my opinion most customers will be patient enough to put up with it, so long as it doesn’t take days or hours. Preferably you’d do this at the time when the site is least busy (say in the middle of the night).
Of course you’d also need to 301 redirect any old content to new content to make sure you keep you’re “link juice”.
As ScallioXTX said, make a clone of the production environment locally and make your changes, then push your changes to a development domain on the same server and see what breaks.
The question for me isn’t so much what breaks as what might be missing. Suppose I made my development clone on the 1st of the month, worked on changes for two weeks, and rolled it out on the 15th. All the blog posts from the 1st to the 15th are now missing in action. Same thing with all new products that have been added to the store, and the reverse with deleted products - they’ve shown up again. All orders placed during that time are gone. Content added during the development period - disappeared without a trace.
In short, just rolling out the new version would effectively roll BACK all changes that were made while the new version was in the oven. Do I now have to perform a painful manual merge of the old and new systems, individually resurrecting every element that was lost in the transition?
Actually I did the reverse of this - manually rolling out the changes one by one - on a recent renovation project. The alterations were fairly minor, only affecting a few elements, but I had several frustrating moments trying to figure out why the new functionality wasn’t working.
Yes, I’d echo (*no pun) what Scallio said. But keep in mind that by what you have described as long as they didnt ask you to change the schema of the DB you shouldnt be worried about damaging data or incompatibility. you developed something that PLUGS into the same DB… which didn’t change at all.
If you client ask you to re do their DB… then the question goes far deeper and perhaps missing data is not an issue.
I was updating aCMS system I created myself. I wanted to add the ability to have metadata in posts. of course I could go back an edit 13mos woth of post w/o meta data. So I added the field in the DB with a default of “false”; when my PHP gets a “false” for the meta field… it teats it as if the admin has chosen to hide the meta.
in any case, the PHP PLUGS into the DB, fields may be added , and ignored, but no data is lost as you didn’t delete any fields and you are PLUGGING into the VERY CURRENT database ( at most you may the site may need to be down for 2mins to add the fields /tablesnecessary for the new data)
Changing the schema, no - changing the DB, yes. You see, I use MODx. In MODx, unlike Joomla or Wordpress, templates are stored inside the DB. So are “snippets” (PHP scripts that run inside the system) and “chunks” (reusable bits of HTML). So, any major modification to the functionality of the site would require changing the database even if not a single word of content was changed.
One could run a DB “merge,” keeping the old copies of the content tables and store tables, but updating the template, chunk, and snippet tables to the new site version. In fact, this is the only plausible way I can imagine doing it on MODx with a large installation. The trouble here is that you would have to make good and sure that no snippets or chunks got added or modified in the interim - which means, at the least, no updates to the CMS plugins, which could be a security problem. There might be other issues with this approach as well; I would really have to try it to find out.
I see I have strayed into a discussion that’s very much MODx-specific; I meant this to be a more general question, but it’s really hard to get across the problem I am facing without the details of my specific situation. I am sure that other CMS’s would have challenges of their own in this scenario.
It’s a really tricky one… in my experience I’ve found “slowly” migrating to a new style or site design works best and impacts my search engine rankings the least.
It sounds like you are not the only person working on the site. Is that right?
Being not too experienced in such matters, I tend to take a very timid approach to the kind of situation you are describing. If I want to change something significantly in a CMS (I use ExpressionEngine, which is similar to MODx), I often copy the output source code of the page in question, create a test page, paste in the original code, create a test stylesheet etc … anything that might change, then get the code working as I want it, then update the chunks of code as necessary on the real pages. That is, while I’m testing, all the bits of code that are normally stored elsewhere (like snippets) are just part of the page’s code. Then when all’s working well, I cut them out again and update the various snippets and other bits in the DB. So it’s a bit like creating a cloned site, but really just working on the live site.
Even though your site is being updated daily, I’d be surprised if those updates relate to the parts you’ve been asked to modify—templates, structure, and look. So it should be easy enough to play with these factors without it affecting the content much or at all. Or am I missing something?
It seems like the issue more so lies with modx than anything. From experience updating and adding functionality is something very easily accomplished in something like Drupal. modX has a small community… unless you can find some type of migration script your probably going to be writing one yourself. I’ve used modX myself and I could barely understand the convoluted interface, god forbid any average user could actually make meaning out of it. Maybe this becomes more an issue of picking the right tools for the job, than anything else.
In my theoretical scenario, there would be more than one person maintaining the site. In reality, on this particular project, I’m basically a one-man band. (: So, making sure that no updates happened in the interim would be as simple as remembering not to step on my own feet, which is (usually) not too challenging. I posed the theoretical scenario rather than something closer to my actual project to make the question as clear and broad as possible.
It sounds like you are ending up doing exactly the same thing with EE that I have been doing on MODx - making careful, “tiptoe” modifications to the live site, using duplicated pages and elements to test everything before rolling it out a tiny piece at a time - and it would appear that betterwork is taking this aproach also.
@oddz
If the situation I have described could be easily handled in Drupal using a pre-made script and workflow, my hat is off to Drupal. (Actually my hat is off to Drupal anyway - it seems to be to big corporate websites what Wordpress is to blogs). I would really love to hear the details of how this would be accomplished, if you have time.
Back when our team was choosing a CMS, we tried Drupal and found its theming system somewhat restrictive; also it was overkill for small sites, which is mostly what we do. MODx is good for all sites, from huge to tiny, and its ease of templating is one of its most well-known features. As far as its interface being confusing, I suppose it might seem that way to someone who was used to something else, but I find it very intuitive - also, the MODx website has a number of testimonials about how easy clients find the backend interface.
Just for grins, you might want to try MODx Revolution 2.0, if you haven’t already. It has a totally revamped backend using ext2js, and is even better than before.
If indeed the difficulty I am describing is only pronounced on ultra flexible CMS’s like MODx, that fact wouldn’t come anywhere near to luring me away from the system. Like ralph.m and betterwork, I can work around it
