Sometimes you discover a site that is so simple and so useful that you what to tell the world about it, unfortunately the more people using it the less valuable it becomes. So, keep this one to yourself 
Up to this point Southampton has been famous for five things…
1. Boats that almost make it to New York.
2. WWII fighters with cool names.
3. All the nice green and watery stuff that surrounds it.
4. A shorter commute into London than the commute for Londoners.
5. And us, naturally!
But now a specially commissioned survey of the 15 largest cities in the UK reconfirms what we knew all along - Southampton is a pretty cool place to be stranded. Men’s Health Magazine compared the cities in a number of categories, using 3 or 4 criteria in each case to draw up rankings. In these rankings Southampton was both the greenest and most hard-working city in the UK, and also the second fittest city behind London. Overall Southampton was…
1st Greenest City
1st Most Hard Working
2nd Fittest
2nd Least Dangerous
3rd Thinnest
5th Least Boozy
6th Cleanest
8th Sexiest
On the downside we were also the third most expensive city to live in, the second least sex-obsessed (not sure if that’s a good thing or not?) and also the 2nd worse city for single men. However, that must mean that we’re also 2nd best city for single women!
Overall it just goes to show why we’re all here in the first place, and why I….umm…live in Christchurch?!
We often encounter the situation where after a large, content-managed website has gone live, the client wishes to add sizeable new features and sections. Sometimes the site is planned to launch in phases from the outset. The new features and sections will often require new code that needs testing and approval by the client before it gets put live, and new data and content needs to be added to the database, or existing data needs amending, using the content management system, in order to test the code fully.
Sometimes it may take a significant amount of time for all the content required by the new developments, to be added to the database. During this period, the content of the site may be incomplete, incorrect or even the code may not work without the required content!
To reduce these undesirable consequences, we release the new code for testing on, and add content to, a copy of the site on our staging area. This uses a different database to the live site, so clients and our guys working on the project can test code and content, safely in the knowledge that the live site won’t be affected until we’re ready.
However, there is still an issue when it comes to migrating the content added to the staging database, to the live database. There would normally, inevitably have been changes made to the live site’s content between the time the copy was taken and put on staging, before the development started, and the time we’re ready to deploy the new code and content back onto the live site.
Content in databases is usually assigned a unique ID (incremental numbers) at the point it is added. When content in one section of the database relates to another piece of content in another section of the database, we use this ID to link the 2 pieces. These relationships can get incredibly complex, with many different pieces of content all being related to one another using their IDs.
If new content is added to both the live and the staging databases after the copy has been taken, both pieces of the content will be assigned the same ID, thus making it impossible to simply copy just the new content that has been added to the staging database, back to live when we are ready.
There is only one really fail-safe solution to this problem, which is to impose a content freeze on the live site, from the point at which the copy of the live database is taken to staging, to the point at which we copy it back to live. I.e. no content may be added, deleted or updated during this period.
However, we can minimise the impact of the freeze by excluding certain parts of the database, such as public member details and sections that drive data-driven parts of the site that are un-related to the sections being developed in the new release. Alternatively, we do not have to enforce a strict content freeze, i.e. small, urgent amendments can be made to the content, but these amendments will need to be remembered and re-done once the staging database is copied to live.
I’ve posted on this topic really just to let people know about the implications of post-launch releases of this size, and explain the reasons behind some of what us programmers do.
If you are a client and this situation applies to you, we will let you know in advance so you can make all urgent updates that you have in the pipeline before the content freeze needs be applied. If you have any questions, please contact your account manager.