If you follow the PHP blogs, then you are likely to have read Matt “WordPress” Mullenweg’s anti-PHP 5 rant:
PHP 5 has been, from an adoption point of view, a complete flop. Most estimates place it in the single-digit percentages or at best the low teens, mostly gassed by marginal frameworks.
He makes some good points in the post. He also manages to make himself seem like a bit of a dick 🙂
The thing that I keep wondering is if we aren’t seeing a slowdown in general PHP adoption due to other technologies being able to get a leg up while PHP 5 was in development and the succeeding slow migration from PHP 4 to 5.
Now that I work for a company creating Java-based software, I see:
- Zend on the PHP-side, who are happy to announce version 1.0 of object-oriented Zend Framework and J2EE on the Java-side already out there on the market for quite some time.
- On the Java-side, Alfresco continuously and quickly building a high-quality ECM based on Open Source Java components and on the PHP-side eZ Systems who yet do not have their flagship ECM product migrated to PHP 5.
Finally, with PHP 5, it is possible to build OO libraries able to compete with Java libraries as far as quality is concerned – but, well, those Java libraries already have a long market track-record, i.e. have been in production use for a long time.
My impression is that PHP 5 slowed down the development of PHP applications able to compete with similar Java-based server-side products. The problem being that migration from PHP 4 to PHP 5 consumes quite some developer resources for complex PHP applications. Additionally, PHP 4 keeps developers busy with finding workarounds for their applications due to limited OO features.
Did PHP applications lose market share or at least not grow as fast as their Java (or C#, etc.) counterparts due to the slow adoption of PHP 5? Unfortunately, I did not find an informative basis to answer this question sufficiently and would appreciate any hints.
Sandro Groganz 
Thanks Sandro for this post. I think this is an eye opener, even when you don’t have a fazit at the end. It makes it quite clear what currently is happening.
PHP Applications are currently nailed on its many years old PHP4 capabilities. When you look for example at the eZ Components and their clear, easy to use and extend interfaces, everyone should quickly recognize that forcing PHP5, like it is currenlty done, helps further development and professionalisation of PHP based Software.
Why? Simple answer as well here, imagine how fast you can build new functionalities with such powerful components. Additionally you keep extendable and don’t have to do a hack for a hack for a hack and stick in a dead end. You will be able to satisfy your customer much faster and customize your software much better to his needs.
I hope that the php5 decliners will soon stop whining and recognize that they get more power for free. I mean where is the problem? If they want, they still can do most of the things like they did in php4.
I also don’t see any risk for the php adoption. There is already a large userbase that is able to code php, many hosters which will continue with their PHP offers. The documentation is still on a high level, and many magazines and other resources are education the people on PHP5 useage for some years now as well.
Its a chance for all PHP users to raise their knowledge again and unveil new powers they havent dreamed of before.
LikeLike
Sandro,
there is a big difference between PHP and Java. Although Zend and some peoples here would like to see something else, PHP is a language used mostly by small companies. If you get statistic about every site that uses PHP scripts, you will see that 90% of them are on shared web hosting! Many of these websites even don’t have full-time or even part-time programmers. They just ordered scripts (like vBulletin) with installation and use it. These website owners don’t know and don’t want to know difference between PHP4 and PHP5.
With Java, there is completely different scene. 99% of sites are on dedicated webhosting. 99% of these companies have at least one full-time programmer.
I hope it is self-explanatory why is it easy to do new things in Java-world, and why it takes so long in PHP world.
It is only problem caused by Zend that there is no 100% backward compatibility between PHP4 and PHP5. If there will be full compatibility, all hosters would be upgraded long ago. Right now, they are not going to take any responsibility for broken customer websites, and I can understand them.
LikeLike
Alex: I think that’s a very good comment. The differences between Java and PHP in this case are interesting. I only wonder how does PHP’s adoption (90% shared hosting users as you said) compare to the Web in general? Is it also 90% shared-hosting environments for the rest of the web, not only for the PHP world? Is it more or less?
Also, why is Zend responsible for the (very little) compatibility breakage between PHP 4.x and PHP 5.x ?
LikeLike
Comparing PHP with Java is like comparing an egg timer with a flux compensator. There is no point in having OO property restrictions in a compilerless always-source-available scripting language. Magic __set and __get methods are useful, exceptions are nice, but the remaining additions of PHP5 make little sense for what it is practically used for.
And after all, you can’t blame users or providers. They neither eschew it, nor did they cause the current situation.
It’s the non-design of the original PHP4 that you should bemoan (or get the flux compensator for.)
And, btw, the lack of a pre-enabled bytecode cache probably didn’t further the PHP5 adoption curve either.
LikeLike
Shahar,
If we count by domain names of published websites, I believe 90-95% of websites are hosted on shared webhosting. I’m saying this based on my customer base (I’m selling a commercial PHP script). Of course, if we count by popularity and traffic, I think 80% of web traffic is going to dedicated webhosting, and 20% to shared (my estimate only).
I don’t blame Zend, but if they were interested in fast migration to PHP5, they should make PHP5 100% compatible with PHP4. Because hosting providers are not going to debug customer scripts that will break after update. Even if there is one line to change, it is “mission impossible” for many customers.
LikeLike
I’m sure you’re correct that as PHP5 was introduced, established PHP projects suffered, since many who had spent time pushing them forward were first to dive into the new terrain. I think there’s more to it, as well. As those on the bleeding edge of PHP got comfortable with PHP5, the new features gained the attention of developers from other languages (notably java) who didn’t really take PHP seriously before. Developers from other languages got involved, and companies using other languages became interested. Three years ago, full-time PHP jobs were pretty rare: If you worked in PHP you worked as a hired gun. In the time since PHP5 showed up, most of the strongest developers I know are now working full-time for salary, doing either PHP5 work or 4-to-5 upgrades. They don’t have a lot of free time anymore, either. Those that are working on open source projects are primarily helping nail down frameworks.
In short, the bleeding edge of PHP changed course. They went from building finished projects to building infrastructure. It’s not as visible right now, but it’s gonna make a lot of difference next year.
LikeLike
I don’t see on how PHP5 will hurt the PHP adoption, it’s more about the slow transition of application from PHP4 to PHP5. Besides, the adoption also influenced by othe technology like Ruby or Python, which are good scripting language.
We have developed our new application all in PHP5, we love the enhancement in OO. But as one said, it’s quite difficult if you need to “convert” from PHP4 to PHP5.
LikeLike
I think PHP5 does not hurt the PHP Adoption, but rather speed it up. Not in the market that is already using PHP… they are happily using PHP4 and have no reason to move unless software is being built for PHP5-only (see the Go PHP5 effort).
However, with the advent of PHP5, PHP has become more and more of an enterprise language. As MonkeyT says, interest from developers from other languages has been peeked, and bigger companies are more and more considering PHP as an alternative to the languages that they have been using already (Java mostly I guess).
LikeLike
Frankly I say let Mr. Matt â??Wordpressâ? Mullenweg keep wasting his energy railing against change instead of using his energy to embrace it. In four months support for PHP 4 will cease, bugs and exploits will no longer be fixed (2008-8-8); and if WordPress doesn’t play catch-up I’d imagine you’ll see community support dwindle. After all, who wants to develop for a dying platform?
As programmers we’re also users of programming software and languages like PHP 5; and like most users we’re all embarrassingly scared of change and the work it can cause us. Embrace it. Rally the WordPress Community (and other PHP 4 based projects) to retool their software. In theory, using things like magic methods, you could even make an object-oriented plug-in framework for WordPress that is backwards compatible with the current implementation.
Since the Zend Framework was mentioned in the article, take that as an example of how to run an open source project. Look at the speed with which such a quality framework was delivered. Personally I think, if the WordPress Community could rally, they could easily roll out a PHP 5, object-oriented version of this fantastic project by the end of the year.
LikeLike
PHP5 is not finding greater adoption because there is simply no market for it. Unless web hosts transfer their websites over PHP5, this situation is going to remain just the same.
Also, there is really no compelling need for PHP5. Ok, OO is a good thing, but frankly very few PHP projects use OO very much.
There is simply no absolutely MUST HAVE feature in PHP5. If it had include a pre-compiled bytecode option which would give PHP5 apps an order of magnitude increase in performance over PHP4 and if there was an option for web hosts to have both PHP4 and PHP5 installed on the same server, then perhaps PHP5 adoption would have increased.
LikeLike
My company published two large PHP based systems and PHP+MySQL remains main platform for further development. We’ve started this 2 projects 7 years ago, when PHP3 was the standard. We had no difficulties in adoption to PHP4, and also for PHP5. I realy can’t understand charges why PHP5 is not combatible backward. Swithing to PHP5 took us about a week. Why? Because of 2 reasons:
1. Our application is well planned (OO) since PHP4
2. We have sandbox server where we switched to PHP5 firsts, checked everything and then switched PHP4 to PHP5 on production servers. This was rather som bugfixes operation than rewriting whole code.
Why we use PHP5 although we have 10+ own servers and 10+ programmers? Because is vast very efficient environment for runtime and development. I think many people misunderstand PHP5 and PHP4 differences and think that PHP4 application need to be completely rewritten into OO. That’s mistake. Changes in constructors, adding private public statements etc. are only cosmetics. We still have few percent of code not touched since 5 years and it works fine.
I think the whole thing is that PHP4 is wide available as packages to Linux systems. PHP5 need compilation what is large problem, even for advanced developers. Many of them talks about compatibility while the case is in installation. I recommend downloading and installing Zend Core. This is really nice way to switch finaly into PHP5 and forget about whole the chit-chats.
* sorry for english mistakes, but i’m not native english speaker
LikeLike
@pkphilip: Good points all area. I’ve got a couple of thoughts to add in response.
In the shared hosting realm where PHP 4 has become so popular, providing a bytecode cache would not have made a bit of difference, since most of these shared hosts already run the Zend Platform, which provides caching already. If I’m wrong on that, please correct me 🙂
In response to your comment that “OO is a good thing, but very few PHP projects use OO very much.” You’re right, but just because they don’t use an OOP model doesn’t mean they couldn’t benefit from it. In my opinion the problem between PHP 4 and PHP 5 isn’t the incompatibilities in the versions of the language, rather it’s in the difference in the developers that use them.
Many popular PHP 4 applications are evolutions of personal projects, often written by designers and other nonprogrammers out of necessity. When you look at the code and, quite often, the support and security history of these projects, it’s obvious to see that the projects are successful in spite of their code quality, not because of it.
I support adoption of PHP 5 because it’s the first release of PHP 5 that feels like a “real language” to me, not just a cobbled together set of commands. I want the power and expressiveness available in PHP 5, and I’m going to be pretty grumpy if non-developers stall it’s adoption. 🙂 PHP 5 isn’t *that* big of a step. And I’m not sure why Mullenweg is complaining anyway: I’m running the latest version of WordPress with a whole host of plug-ins and it works just fine on PHP 5.
LikeLike
Brian – Matt is not complaining that WordPress cannot be ported to PHP5. Actually, WordPress already works with PHP5. What he does not want to do is make changes in WordPress that would cause it NOT to work on PHP4 just because someone thinks that would be the “right” way to do it.
To quote Matt – “WordPress works just as well with PHP 5 as 4, and there are no features on the roadmap (including ones on your list) that would require PHP 5. The only reason for us to break PHP 4 compatibility would be political, and our users without the ability to upgrade their server would be the ones who lose. WordPress doesnâ??t make PHP 4 interesting or not, itâ??s agnostic.”
Seems like a reasonable stance to take.
LikeLike
@pkphilip:
That stance is absolutely reasonable and I’m glad you corrected me. I do think, however, that WordPress would benefit from a refactoring of code, perhaps with forwards compatibility in mind. For example database access could be moved to an interface/class structure. This hypothetical interface could be reimplemented to easily access a variety of data stores, which has always been a flaw in WordPress’ design in my opinion (maybe not so much a flaw as simply not an important feature to the developers). PHP 4 has classes too. Great! So write classes that are compatible with both versions. This is just one example among many.
Again, thank you for the clarification. And I don’t mean to sound ungrateful to Matt and the other WordPress devs. I’ve been using it for years and I love it. From a fellow developer’s perspective I’d just like to see better coding standards within it.
LikeLike
What’s the problem with PHP 5? Nothing if you ask me. Still easy and lightweight compared to Java. Coding objects in PHP doesn’t take any longer than standard scripting if you know what you’re doing, and the code is easier to maintain. The new features like simpleXML are awesome too.
LikeLike
I don’t think Matt’s post was an “anti-PHP 5 rant”… It should be read more as userland-to-PHP message 🙂
The WordPress story is a classic example of what made PHP successful: one person, with little/no programming background, builds a web application to solve his own need and, by open sourcing it and developing it based on user input, it becomes the most popular blog platform.
In my opinion, a few unique featurs of PHP made it fit this pattern of development so well:
1. It is easy for a non-CS-grad to develop in, allowing users like Mullenweg to easily transform into authors, in true “scratch own itch” manner.
2. It is easy for hosting company to install and maintain, allowing users to easily install PHP apps. The supply of cheap, easy PHP hosting far exceeds any supply for Rails or Python or Java hosting.
Measuring PHP5’s effect on the above, you may begin to see the reasons for the lukewarm response it recieved. The new object model is a good example – most people writing PHP (as opposed to “PHP coders”: the beauty of PHP is that most people writing it are *not* coders) don’t need/understand it, and it actively damages the host side, as it hurts some backward compatibility.
LikeLike
@Nir: While those can be advantages of PHP, they’re also disadvantages.
PHP has a reputation for being horribly insecure and for breeding insecure programs. That is only partially undeserved. In the PHP 4 era, you had register_globals (security disaster on wheels), most database access was done via mysql_query() with no automated escaping (which means everyone forgot to do so at least some of the time), and $_GET/$_POST were accessed and echoed directly. You also had hundreds of online tutorials encouraging people to do exactly that, many of which were written in the PHP 3 era and never updated but stayed around in Google way past their shelf life.
In PHP 5.2, register_globals is off and if you turn it on someone will come and beat you over the head with a mallet for being an idiot. You have PDO (or mysqli if you prefer), which offers prepared statement support for SQL which neatly avoids nearly all SQL injection issues when used correctly. You have filter_input() and filter_var(), which makes accessing user input much safer by default.
Non-CS-grad people scratching their own itch in PHP 4 very easily leads to big flashing “hack me” signs on web sites. Sad, but welcome to the modern Internet. In PHP 5.2, if used intelligently, it’s much harder to shoot yourself in the foot due to ignorance.
That’s why it’s important to encourage its use as widely as possible.
LikeLike
@Larry,
You hit the nail precisely on the head 🙂 Good job!
LikeLike
@Larry: register_globals was switched off back in PHP 4.2.0, if I remember correctly (interesting to note it probably broke a lot more existing code than the PHP5 changes, but went over relatively quietly…), and mysql_real_escap_string (now there’s one, er, interesting function name ;)) was introduced in PHP 4.3.0.
The key point here is, as you write, “if used intelligently”. IMHO, any current web environment is about equal in terms of security, if used intelligently, and equally vulnerable if not. Enough to mention XSS/CSRF which are still left to the coder, and issues like using SSL when asking for passwords, which are outside the code itself.
I agree the average level of PHP 5 code available is better than PHP4. That’s because it’s used by less people, who tend to know more about what they’re doing. By the same token, the average code level in Ruby is probably higher yet the average Erlang code tops both. Personally, I judge a language success by the number of people using it rather than average level of code (and frankly, isn’t ease of learning PHP’s strongest selling point? It’s not like it threatens Lisp’s place in CS curriculum, you know ;))
LikeLike
@Nir: Yes, the easy learning curve is a key reason for PHP’s success. However, part of good system design (for any given system, computer or otherwise) is making it easy to do things the right way. Most of the PHP-for-newbies documentation out there is targeted at PHP 3 or PHP 4, and teaches very bad practices. That’s a problem, especially when those newbies get lucky and produce something people start actually using.
A properly set up PHP 5 makes it easier to do things the “right way”. We can get people started on the right foot from the get-go (filter_input(), prepared statements, etc.). That’s good for everyone.
LikeLike
I fully agree with matt. I managed technologies choices and i work with Java, .net and PHP. I was a php fan since PHP/FI, and PHP5 introduce a break in my mind ;o).
From a simple script language, easy to teach, easy to develop quite clear to modify,… PHP5 had becomed as complex as Java (for the same reasons ) and had leaving it own place to become a java concurent.
Object introduction in PHP isn’t the reason, I think it’s more because PHP had copied java implementation view of object.
Object was a requirement for PHP evolution, but not like that.
So i think PHP will die (with a look to php6 roadmap), and other languages like ruby will take the place in a few years.
LikeLike
@bip:
are you notice that you Can write procedural code in PHP5? just in the same way that you did in PHP4…
the OOP and advanced features are Optional.
Look at mysqli extension, OOP and Procedural options.
So PHP5 IS easy to learn, easy to teach.
PHP will never die.
LikeLike
Here’s the issue as per the article (since most comments seem to miss the point)… you have a large, complex, 100 page, 10000 lines of PHP4 for a detailed web forms application.
Now, without some major re-writing, it doesn’t work on PHP5. Since major re-writing takes time, it’s a good opportunity to analyze the platform.
PHP5 is out now, well guess what PHP6 won’t work with your PHP5 code, so why bother? Clearly compatibility is not an issue.
So, the complex web form needs to be re-written. At this time the client, not wanting to be burned by PHP changes in the future, moves to the .NET platform.
They already have Windows Servers in place, ready to go. And this means they can also get rid of their Unix boxes (which were only there to provide PHP web forms).
Sounds like PHP dug it’s own grave.
LikeLike
Ben,
No platform can have BC forever. Even the Windows platform is cutting off legacy stuff, finally, and supporting all that old code is one of the reasons Windows is so crufty and buggy. Code that never has to be upgraded for decades is a think of the past, for better or worse.
That said, well-written PHP 4 code doesn’t need “major rewriting” in order to work in PHP 5. Buggy and sloppy code might, but buggy and sloppy code needs a major rewrite already just because it’s buggy and sloppy. Similarly, the main thing so far that will break in PHP 6 is that register_globals and magic_quotes are being fully removed. If your code relies on register_globals or magic_quotes, then you’re already screwed because those are insecure and you need to rewrite anyway.
That’s the point. Migration from PHP 4 to PHP 5 to PHP 6 is not a massive rewrite for good code. It’s only a massive rewrite for sloppy or poor code. And if you have sloppy and careless code to start with, then you’re screwed no matter what language or platform you’re on.
(Minor tweaks and changes and fixes are likely, but that’s true of any non-trivial program with a major platform upgrade, even BC stallwarts like Windows or Java.)
LikeLike
The BC breaks between 4 and 5 are described in a single page of text on the php.net site: They’re not major at all. PHP6 is going to be a noticeable break in BC just because some very bad shortcuts implemented in PHP’s past are going away: register globals, magic quotes, safe mode, etc. The majority of commands will still be valid: the update will prevent many bad programming techniques. The improper use of these bad ideas already cause the vast majority of security headaches (and bad press) within existing PHP projects that used them. If a company/project relies on them, they are already in trouble and in are dire need of rewritten code. If a company is going to argue the strengths and weaknesses of various languages, I want a stronger, living language with a more powerful roadmap, rather than weak language with a colorful history and a flawed reputation.
LikeLike
I don’t agree with you. I think PHP 5 has hurt PHP.
The group who makes sure PHP (zend? not that it matters) is 100% stable and they have a manual on PHP.net and I might say, “Where do I cast the type of the variable when I initialize it?” on the Variables page. Is the manual a work in progress? My post is deleted. Uh. So I walk away thinking PHP does not support it and never will.
I’m assaulted with your reasoning at this point:
Problem 1: Version 5 does not support it (Version 6 would like to) so how do you ‘properly’ and not ‘lazily’ write the code? Without or with type casting? There’s no answer that makes sense. I’m not 100% where PHP stands with type-casting and I don’t want to have to deal with that.
Problem 2: Just because the version that currently the ‘topic of this page in the manual’ does not include type casting, shouldn’t you reference it? Especially if you don’t want to program a certain way? Can you use features in PHP that aren’t programmed into it yet? How’s that possible?
Problem 3: Regardless no one that is working with the system in my example was involved with programming it. We don’t care how or why the programmer programmed a certain way. It either runs or it doesn’t with an identical server (Only this time using PHP5). A rewrite will either take a lot of time or no time at all. Some features will be in PHP 6 that are not in PHP 5 so nobody has a desire to leave 4 until 6 is done. Problem is, it DOES require a rewrite and the PHP6 rewrite will be longer. It’s management’s decision what we do, why do you think we are concerned with which direction we are taking?
Problem 4: .NET beat Java. The GUI issues in Java that don’t exist in .NET is a good example. Oh right those are today’s languages, not PHP or ASP from the year 2000.
PHP works fine for what it does but it is a language in development. .NET and Java were created and released by companies so the level of complexity of the programming power matches the size of the task.
But I understand you love PHP as much as I loved ASP. PHP is a good language, no doubt about that.
LikeLike
Any chance of PHP on the .NET framework?
Or would it be too similar to C#?
LikeLike
Yes, the comments in the php.net online manual are pruned periodically. They’re not for support questions, but for user-embellishment and tips. For support questions, try the php-general mailing list. It’s quite active and usually quite helpful.
I think you’re missing the point, though. In 99% of cases, you don’t cast a type of a variable when you create it (unless you’re instantiating an object), because PHP doesn’t care. It’s a weakly typed language, by design.
$an_integer = 1;
$a_string = “1”;
In 99% of cases, both will do what you want. If you really really have to cast it, you do it the same way as in C:
$a_string = (string)$an_integer;
From the sound of it, you’re saying you want PHP to tell you how to do strict typing. If you really want strict typing, you should not be using PHP in the first place. 🙂 That has nothing to do with sloppy code; that’s the way the language is designed to work.
The “companies make Java and .NET so they must be better” logic also falls flat on its face. The open source movement if nothing else has blown that fallacy out of the water completely.
PHP 4 is “from the year 2000”. PHP 5 is a “today’s language”. That’s the whole point of pushing PHP 5 adoption! 🙂
LikeLike
If that’s the case I would support PHP4 until the sun explodes.
When 8-2008 rolls around, the love for PHP4 stops.
That’s a shame.
LikeLike
Er, why? 🙂 No version of PHP provides strong typing. I doubt one ever will. If your problem with PHP 5 is that it doesn’t provide strong typing, then you really shouldn’t be using PHP in the first place and the version is irrelevant.
LikeLike
Does PHP 5 hurt PHP? Actually it is exactly the opposite… PHP4 is old and is harming PHP. Support for PHP4 should have been dropped a long time ago. Why because technologies evolve and if PHP doesn’t evolve with it then it will eventually fizzle and die.
The migration from PHP4 to PHP5 is quite easy and I don’t see what people complain about. PHP5 does have compelling features like PDO, OO speed improvements, and more.
LikeLike
When an user asked a php cms ( geeklog ) to develope a roadmap for php5 they [ Dirk – a core developer ] replied
“And “no roadmap to go to PHP5″? Geeklog runs just fine on PHP 5 – no need for any roadmap …”
http://www.geeklog.net/forum/viewtopic.php?forum=6&showtopic=78913&show=20&page=2
If core developers are reluctant I wonder where it hurts them !
LikeLike
Just wait until PHP6 or PHP7, that’s my recommendation.
LikeLike
Since PHP4 will no longer receive security fixes by the end of this year (2007) to wait for PHP6 or PHP7 will be a security risk.
To skip PHP5 and wait for 6 or 7 is also a great way of allowing your PHP development skills to become obsolete while you are waiting for the next version.
LikeLike
The decision to not release Security Fixes for PHP4 is not mine to make.
Since the decision has been made, I can pass judgement on the decision itself. My actions do not come into play here.
PHP4 and PHP5 and PHP6… security fixes will be an issue no matter what you choose.
I think it would be best to go with a different language if security is your primary concern. There is no reason to stop security fixes for PHP4, but since they will stop, now is the perfect time to ‘move on’.
Just my 2 cents. Once bitten, twice shy.
LikeLike
To learn the changes between PHP4 and PHP5 is less than a couple of hours of effort. To make the changes necessary for a project to work on PHP5 are rather minor and if it was developed with known best practices it will require no changes at all. So what is the big deal of moving on to PHP5?
Moving a project to a new language will require a 100% rewrite vs 0-5% changes from PHP4 to PHP5.
The PHP programming language must move on before it and its developers become obsolete.
LikeLike
I agree with the assertions that many sites need very little to no recoding in order to move to PHP5. I was able to run PHP5 3 years ago without a single change in any code.
What is never taken into account is the memory footprint of PHP4 vs PHP5. PHP5 hogs up to double the RAM per thread as compared to ‘old and outdated’ PHP4.
This may have changed in recent versions but, in my experience, an upgrade to PHP5 on a high traffic (80M page views/month) site brought my servers to their knees due to performance and RAM waste issues. I was forced to revert to PHP4 or purchase upgraded/more servers.. in order to run the exact same code!
How is this an upgrade?
As for register_globals being removed at some point. This is the result of the stupid many causing a change for all, whether wanted or not. With correctly coded scripts, register_globals is not a security issue at all. I use them all the time and invite you to try to inject code on any of my sites. Correctly coding cannot be fixed by banning the use of possibly insecure features.. EVER.
I, for one, will wait until the last minute to move to PHP5. Maybe by then it will be optimized enough to compete with it’s older brother.
LikeLike
Edward W: To reduce the resource requirements that you experienced with earlier versions of PHP5.
You could try ‘Zend Optimizer’ or ‘ion cube encoder’. With Zend Optimer’ your code is byte code compile and optimized for performance. With Ion Cube encoder the converted to byte code and the byte code is obfuscated. With this or one of many other methods you can likely get the performance gain you need.
LikeLike
I think the topic itself is a rubbish and outdated!
Sorry if someone get’s hurted, 🙂
I totally agree with what stefan says!
Just take the example of wikipedia.org. It’s #1 website ranked and everybody uses it everyday to know about any unknown concept and it has no replacement till date.
What technology wikipedia uses?
Answer is PHP (from it’s inception).
By moving to PHP 5 , PHP will be become stronger and stronger day by day!
LikeLike