Recent Bun Fight, the e-mail saga
-
If iBIOS is indeed the name of your company, and you are posting under your real name, I am not sure this thread is a very good idea. Whether something's deprecated hardly matters to someone renting hosting space. I am surprised the hotel folks continue to host with you when it's clear that it would be in their best interest to use the hosting company the CMS company recommends (perhaps their own)! Tip: if you are hosting a server that runs someone else's code, try not to install updates that are not backwards compatible.
Regards, Nish
Are you addicted to CP? If so, check this out: The Code Project Forum Analyzer : Find out how much of a life you don't have! My technology blog: voidnish.wordpress.com
Nishant Sivakumar wrote:
Tip: if you are hosting a server that runs someone else's code, try not to install updates that are not backwards compatible.
I would agree; however, security and bugfix updates really need to be installed. Not installing one of these because it might break something leaves the host in a poor position -- update and be in trouble for a site breaking or not update and be in trouble for a security breach. I'd fault the PHP folks for yanking support for something that *was* working in PHP 5 in a point update to PHP 5, whether they've deprecated it or not. The appropriate way to remove the functionality is to deprecate it in one major version and kill it off in a later major version.
-
Hi Guys, I just felt the urge to share this with the world. I apologise in advance for the length of the post, but this is a complete mail trail for a blog that stopped working. I didn't write the software, I host the site it's on. I've only removed surnames and the odd profanity (or two). the rest is "as is": Enjoy! Danny ---------------------- Hi Rob! [Rob owns the company that provided the web site and CMS backend] I cant seem to create any blogs or special offers on our site... The blog I cant write at all and the offers don't save... Am i just being really thick?? Hayley [Hayley works for the hotel in question] ---------------------- Hi Hayley, Umm I have just gone in and uploaded a blog called 'test' and it has uploaded. However it wont show on the home page because it is not showing an image for the blog. I have tried to upload a image and although it is uploading its not showing. This is normally down to file permission on the hosting. The permissions allow you to upload files to the server. Unfortunately Danny is hosting the website, so can you ask him please if he has changed any file permissions on his hosting recently? Regards, Rob. ---------------------- Dan [That’s me. I host the site] Help!! Hay. x ---------------------- Hayley / Rob I've changed nothing on the server at all. Neither files nor access permissions. Danny ---------------------- On 29 Mar 2011, at 13:20, Rob [silly person] wrote: Hi Danny, Lee has had a look at this issue with the [Hotel] website and has found an error with mime content type that is a function in PHP. Lee was wondering if your hosting company has moved your server without you knowing to a different virtual box that has not got these elements installed in the folders? We are guessing that something must have changed as the site has been working on your server for 6 months and now its stopped. We have not changed the site since upload in October, so we cant understand why the admin has just stopped working. Lee has spent an hour on it now trying to find the error message which is: {"status":"system_error","message":"Undefined offset: 1 \nFile = [blurred out for security, but you get the gist]addBlogImage.php \nLine = 83\n"} Can you throw any light on this Danny? Best Regards, Rob [silly person] managing director • [very silly company] ---------------------- On 29 Mar 2011, at 14:57, allnodcoms software wrote: Rob, The error you indicat
I don't disagree with your point overall; however, I agree with others that your tone, especially at the end, is too harsh, especially if you're trying to run a business that wants to keep customers.
-
I don't disagree with your point overall; however, I agree with others that your tone, especially at the end, is too harsh, especially if you're trying to run a business that wants to keep customers.
Point taken - if The Hotel was in fact a client. They are in fact friends of mine (hence me hosting the site - not the devs) and I was just trying to stop them getting shafted by people who were basically trying to pull the wool over their eyes. Danny
-
I think you missed a key point. If I read correctly,
Danny wrote:
library carries a copyright notice dated 13th September last, over a full year after The PHP Group (the language's governing body) announced the deprecation of the code you shipped. The mime_content_type() function was phased out on or around the 23rd of July 2009
the website was written AFTER the code was depreciated, it just hadn't broken completely yet. So its not an issue of an existing website that had to be gone back through due to a sudden depreciation, it was a case of website written with already depreciated code.
Programming is a race between programmers trying to build bigger and better idiot proof programs, and the universe trying to build bigger and better idiots, so far... the universe is winning.
Exactly right! If I'd hired a web developer this bad, I'd be looking for a refund, not blaming the site hosting service.
Will Rogers never met me.
-
Now wait a minute. You're saying that the server operator shouldn't install security & bugfix updates? After all, those are updates.
Go ahead and install security fixes and bug fixes. If there is a problem with one of them (as there was in this case), roll it back. Now if it was an independent update that was intended only to enforce deprecation, then don't roll that out. If the situation is more complex (e.g., a security update that is combined with a deprecation enforcement), then I'd say it would be appropriate to deal with the client in a professional manner. One way would be to roll back the update for them. Another would be to apologize for the inconvenience and plainly tell them that downgrades are not supported. If they need to move to another server because of that, so be it... but that is a lost customer. I don't think emotions should become part of the equation.
[
S<T>::f(U) // Out of line.
](http://msdn.microsoft.com/en-us/library/8yk3t00s(v=vs.71).aspx)
-
I think you missed a key point. If I read correctly,
Danny wrote:
library carries a copyright notice dated 13th September last, over a full year after The PHP Group (the language's governing body) announced the deprecation of the code you shipped. The mime_content_type() function was phased out on or around the 23rd of July 2009
the website was written AFTER the code was depreciated, it just hadn't broken completely yet. So its not an issue of an existing website that had to be gone back through due to a sudden depreciation, it was a case of website written with already depreciated code.
Programming is a race between programmers trying to build bigger and better idiot proof programs, and the universe trying to build bigger and better idiots, so far... the universe is winning.
A developer might follow a tutorial, perhaps written before some code was deprecated, then would try the code and see that it works. Then, that developer puts that code on a server and it works still. I don't think see how that makes the developer bad or responsible for changing the code when there is a server upgrade. I also don't see it as necessarily the responsibility of the host to ensure the upgrade will not break anything. In the case that there is an issue, it should be handled in a professional manner (allow for a rollback, politely indicate the problem, or what have you).
[
S<T>::f(U) // Out of line.
](http://msdn.microsoft.com/en-us/library/8yk3t00s(v=vs.71).aspx)
-
Nishant Sivakumar wrote:
Tip: if you are hosting a server that runs someone else's code, try not to install updates that are not backwards compatible.
I would agree; however, security and bugfix updates really need to be installed. Not installing one of these because it might break something leaves the host in a poor position -- update and be in trouble for a site breaking or not update and be in trouble for a security breach. I'd fault the PHP folks for yanking support for something that *was* working in PHP 5 in a point update to PHP 5, whether they've deprecated it or not. The appropriate way to remove the functionality is to deprecate it in one major version and kill it off in a later major version.
Marc A. Brown wrote:
I'd fault the PHP folks for yanking support for something that *was* working in PHP 5 in a point update to PHP 5
I wouldn't fault them for that. Perhaps they upgraded from PHP 5.1 to PHP 5.2. I don't see why they need to wait for a "major" version upgrade (why isn't 5.1 to 5.2 major and 5.111 to 5.112 minor?). Deprecated functions always have this possibility of being yanked, so sure the programmer should avoid them (if they know of them). Still, it's easy enough for a programmer to make the mistake of using a deprecated function (at least in PHP... Visual Studio is nice enough to tell you when you are making use of a deprecated function). I don't think there's much blame to be assigned here... I think it's just a technological reality that needs to be dealt with.
[
S<T>::f(U) // Out of line.
](http://msdn.microsoft.com/en-us/library/8yk3t00s(v=vs.71).aspx)
-
Point taken - if The Hotel was in fact a client. They are in fact friends of mine (hence me hosting the site - not the devs) and I was just trying to stop them getting shafted by people who were basically trying to pull the wool over their eyes. Danny
Danny Martin wrote:
They are in fact friends of mine
Ah, now that complicates things. It's usually best to avoid mixing business with pleasure. Though, honestly, I'd have to reread that entire communication to make any further observations. TLDRR (too long, didn't reread). :)
[
S<T>::f(U) // Out of line.
](http://msdn.microsoft.com/en-us/library/8yk3t00s(v=vs.71).aspx)
-
A developer might follow a tutorial, perhaps written before some code was deprecated, then would try the code and see that it works. Then, that developer puts that code on a server and it works still. I don't think see how that makes the developer bad or responsible for changing the code when there is a server upgrade. I also don't see it as necessarily the responsibility of the host to ensure the upgrade will not break anything. In the case that there is an issue, it should be handled in a professional manner (allow for a rollback, politely indicate the problem, or what have you).
[
S<T>::f(U) // Out of line.
](http://msdn.microsoft.com/en-us/library/8yk3t00s(v=vs.71).aspx)
AspDotNetDev wrote:
A developer might follow a tutorial, perhaps written before some code was deprecated, then would try the code and see that it works. Then, that developer puts that code on a server and it works still
yep I would be one highly subject to do that very thing being very inexperienced still.
AspDotNetDev wrote:
makes the developer bad
I never said he was.
AspDotNetDev wrote:
responsible for changing the code when there is a server upgrade
For a major upgrade I would prolly agree, say from php version 4 to version 5. However this was not the case as php 5 was already running on that server according to Danny. I would see it being developer responsibility if it was a "simple" update such as security or bug fixes. It then behooves the developer to have proper code that was not outdated by over a year when it was written. The fact that he might not have known better does not change the fact that he wrote code that stood a high chance of breaking for the smallest reason. And keep in mind I say that from a perspective of probbly being the most suspect to doing that very thing myself. My lack of knowledge does not absolve me of my responsibility. I am expected to be knowledgeable by the people that hire me to do a job and ignorance is no excuse(notice I did NOT say stupidity there is a difference).
AspDotNetDev wrote:
In the case that there is an issue, it should be handled in a professional manner (allow for a rollback, politely indicate the problem, or what have you).
no arguments there. He did in fact inform them of the issue and how simple it was to solve. How polite he was about it is subject to your definition of politeness. The dev did in fact continue to argue however insisting that his code was not the problem. This seems to me to be just unprofessional. In all honesty my bet would be this scenario, the dev can charge more money if it was a server upgrade and he had to change major code, if it was a dev problem he has to fix it himself. The part that bugged me the most was how the dev continued to insist his code was not a problem, even after being shown(however rudely or not it was done) how simple the fix was, he said they knew about the depreciation but yet the code was written a year after it was depreciated officially. It seems to me he
-
Go ahead and install security fixes and bug fixes. If there is a problem with one of them (as there was in this case), roll it back. Now if it was an independent update that was intended only to enforce deprecation, then don't roll that out. If the situation is more complex (e.g., a security update that is combined with a deprecation enforcement), then I'd say it would be appropriate to deal with the client in a professional manner. One way would be to roll back the update for them. Another would be to apologize for the inconvenience and plainly tell them that downgrades are not supported. If they need to move to another server because of that, so be it... but that is a lost customer. I don't think emotions should become part of the equation.
[
S<T>::f(U) // Out of line.
](http://msdn.microsoft.com/en-us/library/8yk3t00s(v=vs.71).aspx)
AspDotNetDev wrote:
I don't think emotions should become part of the equation.
I agree with you on that. In a response to another post of mine in this thread, the OP stated that the end users were friends, which was why their site was hosted on his server and why he was more ... uh ... loose-lipped ... than he might otherwise have been. :)
-
Marc A. Brown wrote:
I'd fault the PHP folks for yanking support for something that *was* working in PHP 5 in a point update to PHP 5
I wouldn't fault them for that. Perhaps they upgraded from PHP 5.1 to PHP 5.2. I don't see why they need to wait for a "major" version upgrade (why isn't 5.1 to 5.2 major and 5.111 to 5.112 minor?). Deprecated functions always have this possibility of being yanked, so sure the programmer should avoid them (if they know of them). Still, it's easy enough for a programmer to make the mistake of using a deprecated function (at least in PHP... Visual Studio is nice enough to tell you when you are making use of a deprecated function). I don't think there's much blame to be assigned here... I think it's just a technological reality that needs to be dealt with.
[
S<T>::f(U) // Out of line.
](http://msdn.microsoft.com/en-us/library/8yk3t00s(v=vs.71).aspx)
AspDotNetDev wrote:
I don't see why they need to wait for a "major" version upgrade
Because minor upgrades shouldn't break functionality, unless there's a really good reason. Of course, that's just my arrogant opinion :laugh: but that policy keeps devs from having to deal with a moving target.
-
Point taken - if The Hotel was in fact a client. They are in fact friends of mine (hence me hosting the site - not the devs) and I was just trying to stop them getting shafted by people who were basically trying to pull the wool over their eyes. Danny
I didn't catch the fact that they were friends rather than a typical client. That changes things.