Results 1 to 3 of 3
Dec 1, 2013, 18:18 #1
- Join Date
- Mar 2001
- Melbourne, Australia
- 0 Post(s)
- 0 Thread(s)
How do u manage website owners when an upgrade (eg php) will likely break their site?
Just curious to compare notes with others on this topic - especially with other website design/dev companies who also organise hosting for their clients (as we do).
We all know that - essential security patches/upgrades aside - "let sleeping dogs lie" is most likely to result in the ongoing stability of websites hosted on a server. In other words - change as little as you can about the hosting environment if everything is running sweetly "as is".
But over time of course your server software versions (e.g. LAMP) will become more and more outdated, and eventually unsupported - and therefore potentially increasingly insecure, unless you're running with the "security by obscurity" principle :-). Example: at time of writing, php 5.5.x is the latest version of php, versions 5.4 and 5.3 are still supported, but versions 5.2 and below are no longer supported. My understanding is that if you're aiming for a server that will pass a PCI compliance test, then any server running a version of php less than 5.3 will fail.
So as I see it you broadly have two choice as a website design/dev company who also looks after the hosting of your clients websites:
1. Keep servers "as is" as long as, possible. Don't rock the boat. One day you will want to shut down that old legacy server, but for now you're ok with it ticking along with gradually less and less sites on their as those sites get rebuilt and re-hosting on newer servers (hopefully with you). The cost per site on a shared server will increase as less and less sites remain.
2. Contact affected clients and announce "We need to upgrade php to the latest recommended version on the server where your site is hosted. This upgrade may have affect your site to some degree. We estimate between 'x' and 'y' hours of labour to test your site with the new version of php and fix up any issues @ $z/hr. Ok to proceed". Or words to that effect.
Doubtless if you don't manage it sensitively, then going with option #2 might annoy/alienate/lose you some clients who don't want to - or can't afford - the labour to upgrade their sites.
How do others manage this?
I'm not expecting a 1-size-fits-all answer. Any alternative views or approaches would be much appreciated.
p.s. We notice that CloudLinux appears to be the most popular OS these days for shared hosting - one of the benefits being the apparent ability to run multiple versions of php on the same hosting server, This doesn't get around the above challenge - but it does permit more efficient (cost effective) utilisation of your servers.
Dec 4, 2013, 03:26 #2
- Join Date
- Feb 2002
- 19 Post(s)
- 3 Thread(s)
I offer hosting but utilize a hosting company which updated when new updates become available (presumably on the principal that the updates are (1) fixing bugs, (2) upgrading the services to provide more/better capabilities - PHP upgrades so this more often than not - and (3) to continue to offer the latest and greatest server software available.
Personally, I prefer that approach.
As for the update from PHP 4 to PHP 5, the change from mysql to mysqli did cause some minor problems as the database access code had to be changed. For this, both options were made available and sufficient notice of the impending change (and impact) was provided to allow a smooth changeover.
I have had great success with this host (and the prior one) and believe that their diligence in keeping things current is extremely beneficial to me and my clients.
Dec 10, 2013, 17:01 #3
- Join Date
- Nov 2006
- 40 Post(s)
- 1 Thread(s)
I've had this issue before when hosting a deadbeat client that was unwilling to pay for work to upgrade their legacy application to remain functional on a new version of php.
In their case I moved them to a single site VPS account - the time involved was minimal, and having them isolated from other sites means that in the event their older version of php becomes exploited, no other sites will be affected. It's important that you cover exceptions like this contractually, both for hosting and maintenance, and for any term during which you guarantee functionality for their site if you developed it.