3 ms·

Both Flickr and PHP5 appeared in 2004. For one of the biggest PHP sites in the world, I'd imagine they'd upgrade sooner.

by andr 17y ago

deleted 17y ago
[deleted]
nuclear_eclipse 17y ago
PHP5 had a very unfortunate and slow pickup from the developer community, mainly stemming from a wave of backwards-incompatibilities in PHP5, some of which was in the new object model for PHP5, the rest of which was changes to way some core functions took their parameters. There are still some applications that are not yet compatible with PHP5, even five years later and after PHP4 has already been end-of-lifed. It's much like the Python 2.x -> 3.0 migration, in that it needs a lot of attention from developers to make sure applications are ready. The difference is that with PHP, you have scores of uneducated shared hosting clients who don't know anything about their application other than it works in PHP4, but not in PHP5. Hence the reason that it took years before PHP5 outnumbered PHP4 on the webserver...
- encoderer 17y ago
  OK, I'll bite... I'm a co-founder of a software consultancy and we've actively marketed PHP4->PHP5 upgrades after we did a couple large, successful projects that just happened to include upgrading from 4 to 5. We wrote a Compiler that does 95% of the work for us. Took a few weeks to write and it's made our 4->5 upgrade jobs a very profitable part of the business. To the best of my knowledge, there was no changes to function parameters order. It's nearly all object-model stuff. Some might find this interesting.. The 1.0 of the Compiler introduced bugs into the compiled (5.0 version) of the codebase in cases where the orginal dev relied on the Assign-By-Copy behavior of v4. In most cases by-ref behavior is what was wanted, and many probably didn't notice the distinction. But there is a situation where the dev may have taken advantage of the fact that eh was getting a copy, eg: function x($o) { $o->foo = 'bar'; $o->save(); unset($o); } $y = new o(); $y->foo = 'baz'; x($y); $y->save(); This code in PHP4 works as the developer intended. In PHP5 it throws an error on the $y->save line because the object was passed by reference to x() and it was garbage collected inside x. It's rare, but it exists, and it was a little tough to fix because we're running a single-pass Compiler. The nice thing is that it's also able to introduce optimizations in the code, as well as use a Static Analysis approach to detecting probably bugs and security holes (for example, unfiltered use of $_REQUEST values, or assigning to $this) and it fixes them as well. The end result is an app that always runs faster, sometimes significantly so. IMO, the real reason 4->5 was a slow process is because it's biggest selling point was a "real-ish" object model and most PHP developers are Morts and just don't need to care about that.
  - nuclear_eclipse 17y ago
    > To the best of my knowledge, there was no changes to function parameters order. It's nearly all object-model stuff. Now that I think about it, I'm wanting to say the parameter-order hoopla was centered around one of the point releases to 5.x, but I could be wrong. Your compiler is an interesting topic though, and it seems similar to the "upgrade" scripts available for the Python 3 jump. Do you make the compiler publicly available, or no? Would be really nifty to see what all you handle in it.
    - chops 17y ago
      I've venture a guess that "no, it's not publicly available", primarily since he mentioned that it's a very profitable part of his company.
mattyb 17y ago
Can anyone shed some light on the difficulties involved in upgrading a codebase of that size?
- paulhammond 17y ago
  (I work at flickr) The problem is finding all the places that the language has changed and all the places you relied on the old behavior. The documented stuff was easy to find, it was the undocumented (or unintended?) changes that were hard. For example, strtotime($null) returns now in php4 but returns null in php5. QA and automated testing will only get you so far in this process. Nobody had thought to test how we display the "Date Taken" on photos from before December 14th 1901 until a member pointed out they were displaying wrong (caused by another change to strtotime() behavior). At some point you have to upgrade a subset of your servers, watch the error logs, fix the bugs as they come up and be prepared to rollback quickly. It wasn't a fun experience...

Both Flickr and PHP5 appeared in 2004. For one of the biggest PHP sites in the world, I'd imagine they'd upgrade sooner.

by andr 17y ago

Both Flickr and PHP5 appeared in 2004. For one of the biggest PHP sites in the world, I'd imagine they'd upgrade sooner.

deleted 17y ago

[deleted]

nuclear_eclipse 17y ago

PHP5 had a very unfortunate and slow pickup from the developer community, mainly stemming from a wave of backwards-incompatibilities in PHP5, some of which was in the new object model for PHP5, the rest of which was changes to way some core functions took their parameters. There are still some applications that are not yet compatible with PHP5, even five years later and after PHP4 has already been end-of-lifed. It's much like the Python 2.x -> 3.0 migration, in that it needs a lot of attention from developers to make sure applications are ready. The difference is that with PHP, you have scores of uneducated shared hosting clients who don't know anything about their application other than it works in PHP4, but not in PHP5. Hence the reason that it took years before PHP5 outnumbered PHP4 on the webserver...

encoderer 17y ago
OK, I'll bite... I'm a co-founder of a software consultancy and we've actively marketed PHP4->PHP5 upgrades after we did a couple large, successful projects that just happened to include upgrading from 4 to 5. We wrote a Compiler that does 95% of the work for us. Took a few weeks to write and it's made our 4->5 upgrade jobs a very profitable part of the business. To the best of my knowledge, there was no changes to function parameters order. It's nearly all object-model stuff. Some might find this interesting.. The 1.0 of the Compiler introduced bugs into the compiled (5.0 version) of the codebase in cases where the orginal dev relied on the Assign-By-Copy behavior of v4. In most cases by-ref behavior is what was wanted, and many probably didn't notice the distinction. But there is a situation where the dev may have taken advantage of the fact that eh was getting a copy, eg: function x($o) { $o->foo = 'bar'; $o->save(); unset($o); } $y = new o(); $y->foo = 'baz'; x($y); $y->save(); This code in PHP4 works as the developer intended. In PHP5 it throws an error on the $y->save line because the object was passed by reference to x() and it was garbage collected inside x. It's rare, but it exists, and it was a little tough to fix because we're running a single-pass Compiler. The nice thing is that it's also able to introduce optimizations in the code, as well as use a Static Analysis approach to detecting probably bugs and security holes (for example, unfiltered use of $_REQUEST values, or assigning to $this) and it fixes them as well. The end result is an app that always runs faster, sometimes significantly so. IMO, the real reason 4->5 was a slow process is because it's biggest selling point was a "real-ish" object model and most PHP developers are Morts and just don't need to care about that.
- nuclear_eclipse 17y ago
  > To the best of my knowledge, there was no changes to function parameters order. It's nearly all object-model stuff. Now that I think about it, I'm wanting to say the parameter-order hoopla was centered around one of the point releases to 5.x, but I could be wrong. Your compiler is an interesting topic though, and it seems similar to the "upgrade" scripts available for the Python 3 jump. Do you make the compiler publicly available, or no? Would be really nifty to see what all you handle in it.
  - chops 17y ago
    I've venture a guess that "no, it's not publicly available", primarily since he mentioned that it's a very profitable part of his company.

mattyb 17y ago

Can anyone shed some light on the difficulties involved in upgrading a codebase of that size?

paulhammond 17y ago
(I work at flickr) The problem is finding all the places that the language has changed and all the places you relied on the old behavior. The documented stuff was easy to find, it was the undocumented (or unintended?) changes that were hard. For example, strtotime($null) returns now in php4 but returns null in php5. QA and automated testing will only get you so far in this process. Nobody had thought to test how we display the "Date Taken" on photos from before December 14th 1901 until a member pointed out they were displaying wrong (caused by another change to strtotime() behavior). At some point you have to upgrade a subset of your servers, watch the error logs, fix the bugs as they come up and be prepared to rollback quickly. It wasn't a fun experience...