Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Changes In Store For PHP V6

kdawson posted more than 6 years ago | from the ready-or-not dept.

PHP 368

An anonymous reader sends in an IBM DeveloperWorks article detailing the changes coming in PHP V6 — from namespaces, to Web 2.0 built-ins, to a few features that are being removed.

Sorry! There are no comments related to the filter you selected.

Is this really news? (-1, Offtopic)

Adam Zweimiller (710977) | more than 6 years ago | (#23371902)

I know it's mother's day and all, but there's got to be something somewhat interesting going on in the "nerd" world, right? Just sayin', a week old report on the PHP6 *planned* features isn't exactly frontpage news. It's so boring in fact, I felt the need to reply and bash the post just to alleviate my boredom. Neurotic, eh?

PHP and other interpreted languages suck! Use C! (-1, Flamebait)

Anonymous Coward | more than 6 years ago | (#23371948)

I make good money on RentACoder coding up web sites that use binary executables and CGI!

Long live C and character arrays!

Re:Is this really news? (4, Insightful)

truthsearch (249536) | more than 6 years ago | (#23371982)

Especially since most of the "new" features are either already available or will be included in v5.3. There's literally nothing new here except better Unicode support.

Re:Is this really news? (4, Insightful)

bcat24 (914105) | more than 6 years ago | (#23372124)

There's literally nothing new here except better Unicode support.
True, but better Unicode support is a very major feature in and of itself. Let's face it, writing a Unicode-enabled Web application with PHP 5 is like hunting wildebeests with a BB gun. It's possible, but it sure ain't easy.

Re:Is this really news? (1, Funny)

Anonymous Coward | more than 6 years ago | (#23372296)

People USE Unicode?! Back when I was a youngin' we used ASCII and LIKED IT!

Re:Is this really news? (0, Troll)

SanityInAnarchy (655584) | more than 6 years ago | (#23372624)

s/unicode/$foo/gi

I suspect this will be modded troll, and that would be fair. Go ahead. Has to be said, though.

Some languages, I see the point of. I understand why Visual Basic still exists, even if I despise it. I understand why C exists, and even why Java exists.

PHP, I just don't get. Why bother? It's Perl, minus a bunch of features, in a templating language. As soon as you discover that other languages can be embedded into a webpage, too, I cannot think of a single thing that PHP does better than just about anything short of C intended for developing web apps.

The one thing that I can appreciate about PHP is the massive amount of stuff that's already written in it -- like COBOL, it will remain popular and used for that reason alone. But unlike COBOL, it continues to be actively developed, and used for new projects. Why?

Were it just about anything else, people might come to me with code samples, showing at least one niche thing that their pet language does beautifully, or at least, that they believe shows it lacks a weakness of some other language. Prove me wrong -- show me some beautiful PHP code.

Re:Is this really news? (4, Informative)

dgatwood (11270) | more than 6 years ago | (#23372754)

What makes PHP nice is that, language-wise, it is basically C plus a subset of C++ wrapped up in a scripting language. Almost any code written in C (or C++ without templates/exceptions/other icky stuff) can be trivially ported to PHP by replacing the type names with "var" and adding dollar signs in the right places. (I'm exaggerating slightly, but not much.)

PHP doesn't have any weird syntax like Perl regular expressions---you can do Perl regex, but it is neatly encapsultated into proper strings the way it should be. There's no having to manually re-indent dozens of lines of code because you needed to add another nesting level and whitespace is part of the language, etc. It's just a really clean, lightweight OO language that's exceptionally easy to learn and happens to integrate very well with HTML.

Don't get me wrong, PHP has plenty of weak points when it comes to performance (particularly when dealing with massive complex data structures), availability of modules to do various obscure things, etc., but as a language, it is pretty nice, IMHO---mainly because it isn't a kitchen sink like Perl.... :-)

I'm New Here (1, Funny)

New Here (701369) | more than 6 years ago | (#23372474)

I'm New Here

Re:Is this really news? (2, Informative)

NamShubCMX (595740) | more than 6 years ago | (#23372660)

Unicode support is reported to become available for 5.3+ later as a module.

What I've heard the developers say, basically, is that there is no real roadmap for 6.0, since 5.3 has most of the planned features and unicode (the big new thing) will be available sometimes, although not built-in.

Re:Is this really news? (0, Offtopic)

moteyalpha (1228680) | more than 6 years ago | (#23371988)

I just came here to help support open source. The articles may not always be winners, but the tag lines and comments make up for that.

Re:Is this really news? (1)

truthsearch (249536) | more than 6 years ago | (#23372028)

The articles may not always be winners, but the tag lines and comments make up for that.
Exactly [seenonslash.com] . (Warning: blatant plug.)

Re:Is this really news? (2, Insightful)

MightyMartian (840721) | more than 6 years ago | (#23372188)

I simply can't wait for an even bigger php.ini file to support disabling and re-enabling of deprecated functionality. I've spent several evenings over the last few weeks on a contract to clean up some really bad PHP code, and a good fraction of that time has been spent actually getting a test bed up and running, trying to match the Win32 PHP 5 install I'm forced to work with the Linux PHP4 install on the production server. More than ever before I'm convinced that PHP is the worst major language ever invented, and I'll wager PHP6 only makes it worse.

Re:Is this really news? (0, Troll)

Linker3000 (626634) | more than 6 years ago | (#23372282)

You moan - yet you took the contract.

Biting the hand that feeds you just a tad!?

Re:Is this really news? (1)

Enleth (947766) | more than 6 years ago | (#23372412)

Well... Don't take contacts when you're not familiar enough with the technology it requires so that you don't need to struggle with it at all?

As a regular PHP user, I've gotta say... (1)

Ethan Allison (904983) | more than 6 years ago | (#23371908)

This looks pretty awesome.

Re:As a regular PHP user, I've gotta say... (-1, Flamebait)

Anonymous Coward | more than 6 years ago | (#23371954)

you are setting off my gaydar, son

PHP 6 (-1, Flamebait)

Anonymous Coward | more than 6 years ago | (#23371912)

Poop in my Hand, Please, 6 times the usual amount. Thanks!

Content free summary (0, Troll)

mrbluze (1034940) | more than 6 years ago | (#23371914)

Crikey, I can't believe I have to RTFA to come up with something funny to say about this short-ass summary!

Re:Content free summary (1)

ed.mps (1015669) | more than 6 years ago | (#23372042)

you only need to read the 1st paragrahp:

PHP is already popular, used in millions of domains (according to Netcraft)

Re:Content free summary (1)

truthsearch (249536) | more than 6 years ago | (#23372092)

On /. Netcraft can only be used to confirm that things are dead, not alive.

Magic Quotes Removed (2, Informative)

iamhigh (1252742) | more than 6 years ago | (#23371918)

Citing portability, performance, and inconvenience, the PHP documentation discourages the use of magic_quotes. It's so discouraged that it's being removed from PHP V6 altogether, ... ... If you're using magic_quotes to escape strings for database calls, use your database implementation's parameterized queries, if they're supported. If not, use your database implementation's escape function, such as mysql_escape_string for MySQL or pg_escape_string for PostgreSQL.
This was discussed just a few days ago in the some what wrongly titled 500 Thousand MS Web Servers Hacked [slashdot.org]

Re:Magic Quotes Removed (3, Insightful)

robo_mojo (997193) | more than 6 years ago | (#23372308)

So does this mean that if you are using magic quotes and you upgrade to PHP6, suddenly you will become vulnerable to SQL injection attack? Wow, I'd consider that to be a major regression, then.

Magic Quotes (0)

Anonymous Coward | more than 6 years ago | (#23371922)

No more magic quotes makes AC a very happy coder.

Major version? (1)

tomtomtom777 (1148633) | more than 6 years ago | (#23371926)

I don't see why this is a major update (5 => 6).

Soap & XML was already implemented which leaves namespaces and unicode support as new features, and a bunch of stuff removed

Re:Major version? (2, Insightful)

eebra82 (907996) | more than 6 years ago | (#23372030)

I don't see why this is a major update (5 => 6).
If I had a software development business, I would do this if I wanted to push a release a little extra. People don't care as much about decimals as much as they care about entirely new release numbers.

Re:Major version? (1)

Dragonslicer (991472) | more than 6 years ago | (#23372054)

I don't see why this is a major update (5 => 6).
I believe it's because the Unicode support involved a significant amount of work in the engine. I vaguely remember that this means extensions will need to be modified to work correctly, but I'm not certain about that.

Re:Major version? (0)

Anonymous Coward | more than 6 years ago | (#23372192)

Adding Unicode support to a language is a big deal, it's basically a win but it also typically introduces some backward incompatibilities with existing code, and lots of head-scratching about how things are supposed to work. When do strings get converted to/from Unicode, and from what character set? Be prepared to spend some time looking at output from od, or similar, when the data has characters that are outside of 7 bit ASCII.

Re:Major version? (0)

Anonymous Coward | more than 6 years ago | (#23372328)

Adding Unicode support to a language is a big deal,
yay and it only took a few years longer to get there than other web programming languages.

Re:Major version? (0)

Anonymous Coward | more than 6 years ago | (#23372486)

You'd fit in great with Sun's marketing division.

Re:Major version? (4, Insightful)

Splab (574204) | more than 6 years ago | (#23372320)

"and a bunch of stuff removed"

The stuff addressed are some of the widest security holes. On top of that the old way of programming PHP and most guides out there encouraged the usage of these bad functions, getting them totally removed is a huge step forward.

Re:Major version? (2, Insightful)

WK2 (1072560) | more than 6 years ago | (#23372444)

They are removing some things. According to Splab, above, removing these things is a huge step forward. More importantly, removing things should always be a major release. They are breaking backwards compatibility with everything that uses the things that they are removing.

Quick summary (5, Informative)

Anonymous Coward | more than 6 years ago | (#23371934)

... for those too lazy to RTFA:
Additions:
Better Unicode support
Namespaces! (this is being backported to PHP 5.3)
SOAP and the XML Writer/Reader modules compiled in and enabled by default (also in PHP 5.3)
Removals:
magic_quotes, register_globals, register_long_arrays, safe_mode
ASP-style short tags ()
Freetype1/GD1 support
ereg (use of preg encouraged instead).

Re:Quick summary (1)

kestasjk (933987) | more than 6 years ago | (#23372450)

Too bad the backwards-compatibility is going to make migration very slow.. PHP5 is very backwards compatible with PHP4, and the move to PHP5 is still going on, PHP6 will take a long time.

Lose the M in LAMP? (1, Offtopic)

mrbluze (1034940) | more than 6 years ago | (#23371950)

Better XML support. That's a biggie. Might it mean we can, for a whole heap of projects, discard mysql? Would it make things run faster?

Re:Lose the M in LAMP? (2, Insightful)

i.of.the.storm (907783) | more than 6 years ago | (#23371976)

I would think swapping mysql for XML would make things run slower on the whole, especially large databases, but I'm not an expert in that field. XML and mysql really serve different purposes, and I don't think replacing mysql with XML would be a good idea for the vast majority of use cases.

Oh, and what happened to the spiffy discussion2 stuff? Now comments open in new pages again and I can't reply inline. What's up with that?

Re:Lose the M in LAMP? (0, Redundant)

mrbluze (1034940) | more than 6 years ago | (#23371992)

Oh, and what happened to the spiffy discussion2 stuff? Now comments open in new pages again and I can't reply inline. What's up with that?
You have to enable XML on your browser ;) .. err.. Javascript and cookies I mean.

Re:Lose the M in LAMP? (1)

i.of.the.storm (907783) | more than 6 years ago | (#23372044)

Hmm, everything should be enabled properly. Seems like discussion2 is randomly changing?

Re:Lose the M in LAMP? (1)

LiquidCoooled (634315) | more than 6 years ago | (#23372390)

I noticed this as well, the comment titles also used to collapse so i could cull the stuff I've read.
the first time i did it this evening it opened the comment thread from that location.

Re:Lose the M in LAMP? (1)

Foofoobar (318279) | more than 6 years ago | (#23372640)

This actually is a very good observation believe it or not. Most MVC frameworks use XML to load the structure for the site and PHP's XML parser is extraordinariraly subpar so I created an MVC framework whose structure was loaded and cached from MySQL; as a result, it scales better, has a faster page load and blows Zend and others out of the water for speed as a result.

Its not the best approach for all intents and purposes (only 95% SEO compliant) but it has also enable a siwplistic approach for adding an all in one ajax approach and XUL compatibility really easily. Still I wish they would focus on improving XML parsing.

Re:Lose the M in LAMP? (0)

Anonymous Coward | more than 6 years ago | (#23371984)

I personally use PDO with SQLite as a backend. Prepared statements are exceptionally useful. For my usage (a webcomic site schedule) it works great. YMMV of course.

Re:Lose the M in LAMP? (2, Insightful)

cheater512 (783349) | more than 6 years ago | (#23372050)

No.
XML is a format designed to transmit data between machines, not for data storage.

Imagine a 50 gigabyte database. I have one.
Now imagine the same database in XML.
The size would explode and you suddenly have to seek the entire db for a simple select.

Re:Lose the M in LAMP? (1)

truthsearch (249536) | more than 6 years ago | (#23372116)

XML is also designed for small amounts of hierarchical data, e.g. OpenOffice documents.

Re:Lose the M in LAMP? (1)

maxume (22995) | more than 6 years ago | (#23372220)

XML was designed to make it easier to work with structured data by making tools more reusable. In situations where it doesn't make sense, it's just as terrible a wire format as it is a data format.

register_globals (0)

Anonymous Coward | more than 6 years ago | (#23371998)

Yay! Finally not just having register_globals defaulted to off, but removed altogether.

Won't change a thing (1)

cortana (588495) | more than 6 years ago | (#23372326)

PHP scripts will still manually implement it, and each one will do it in a slightly different but still broken way, generating hundreds more security vulnerabilities...

Backwards compatibility is very important (5, Interesting)

unity100 (970058) | more than 6 years ago | (#23372008)

i am servicing around 350+ clients in a small fish web host. even at that small web host, there are a phletora of different scripts, programs that clients are using to conduct their everyday business, their estores, their livelihood. some of them are dependent and locked-in to the software they are using like a small business company that extensively uses ms products is locked into microsoft.

regardless, backwards compatibility is important for those people. for starters, these are the people who have chosen php as the platform to conduct their business on, making php a de facto dominant language for the web instead of being a small time web language that was used on web savvy, webmasters. the financial impact of this is going to be huge for them, to adopt to that many changes php dev group started to introduce in the span of 1 to 2 years. this is too much.

you gotta slow down. or you are going to alienate the small business community from using php with what you are doing. if you break a small estore owner's store script every 1.5 years for 'upgrading', the second time you do it they will jump the language ship.

do not start to become an elitist group out of touch with the people, increasingly caring for nifty programming issues rather than what would the users think.

Re:Backwards compatibility is very important (2, Interesting)

Anonymous Coward | more than 6 years ago | (#23372096)

And forward innovation is not important? Besides, you wouldn't upgrade all 350+ clients at once and in place? Perhaps having two host accounts, one for php5 apps and one for php6? Just a thought.

Re:Backwards compatibility is very important (4, Insightful)

MROD (101561) | more than 6 years ago | (#23372186)

Many commercial PHP-based systems are only now just changing over to PHP5 from PHP4. (Yes, I know...)

That's the way life is, I'm afraid. Most people who are depending upon these sites and software have no control over the vendors and definitely don't have the ability of fixing the code themselves.

Changing the API so greatly and so often in a non-backwardly compatible fashion does cause genuine problems.. and hosting sites can't afford to support multiple versions. Well, not unless they charge their customers too higher price for hosting their pages.

Re:Backwards compatibility is very important (0)

Anonymous Coward | more than 6 years ago | (#23372544)

Many commercial PHP-based systems are only now just changing over to PHP5 from PHP4. (Yes, I know...)

Yes you know what? That's completely reasonable. If you have a system doing exactly what you want, going in to change things just to use a new version is downright stupid.

Re:Backwards compatibility is very important (0)

Anonymous Coward | more than 6 years ago | (#23372190)

..and that's how it started with windows..and is one of the primary reasons it's so bloated and broken today. Hey, no one's forcing you to upgrade right away.

Re:Backwards compatibility is very important (1)

truthsearch (249536) | more than 6 years ago | (#23372222)

Just like PHP 4 was supported for a very long time with security updates, so will PHP 5. Your clients won't be obligated to upgrade for many years.

One major issue with PHP is old cruft, such as magic quotes, that were terrible feature additions in the first place. These are so bad it's really in everyone's best interest to remove them. I think features like POSIX regex, however, should remain because they don't do any harm.

Re:Backwards compatibility is very important (0)

Anonymous Coward | more than 6 years ago | (#23372258)

Then don't upgrade to the latest version until you are ready?

PHP maintains the 4 lineage of php at the moment, and I suspect the same will happen with the 5 lineage.

PHP should not keep backwards functionality where it is limiting the language, and PHP as it is now needs to lose some of the obscure and legacy code.

Re:Backwards compatibility is very important (1)

thetoadwarrior (1268702) | more than 6 years ago | (#23372306)

Who says you have to upgrade to version 6? If you are renting hosting then your host if shit if they don't offer multiple versions of PHP. For instance www.prohosting.com allows you to use either v4 or 5 and will likely offer at least v5 and 6 if not all 3.

Secondly and decent host probably already has registered_globals off and as far as $HTTP_GET_VARS and the like go, do you not have a decent program to find and replace text?

Re:Backwards compatibility is very important (1)

unity100 (970058) | more than 6 years ago | (#23372504)

read my post again.

Re:Backwards compatibility is very important (2, Interesting)

njcoder (657816) | more than 6 years ago | (#23372384)

Sounds like you're using mod_php. That's a very insecure way to run php in a shared hosting environment and also doesn't give you the ability to run more than one version of php.

May not seem like a big deal until some idiot doesn't update his scripts and some script kiddie comes along and you get 350 calls from your clients asking you why there's some terrorist propaganda on their website.

Re:Backwards compatibility is very important (1)

unity100 (970058) | more than 6 years ago | (#23372528)

your ears are weak.

also you should note that, the same customers would make much more stampede when they are asked to pay for development work for their running estores, because php team had decided to deprecate some features, for the second time in 1.5 years.

Re:Backwards compatibility is very important (1)

njcoder (657816) | more than 6 years ago | (#23372550)

sucks to be them

Re:Backwards compatibility is very important (1)

njcoder (657816) | more than 6 years ago | (#23372600)

By the way, you do realize that you don't have to upgrade your server right? You can leave the current version of PHP and everyone will be happy. There are tons of hosts still only offernig php4.

The part where I said there are ways to run different versions of php for different users didn't seem to register for you either.

Re:Backwards compatibility is very important (1)

fimbulvetr (598306) | more than 6 years ago | (#23372722)

Yes, actually very soon you will need to update your server. PHP4 is no longer being updated - this means security and all types of other bugs, including data loss/critical bugs. From now on, security updates will NOT be official and subject to people's whim. It's absolutely retarded that you suggest one can stick with PHP4 and be happy. The happiness will only last until there's no fix for their dataloss bug or their system has been hacked.

Re:Backwards compatibility is very important (1)

MindStalker (22827) | more than 6 years ago | (#23372426)

Realistically its not a huge change, just removal of some insecure features. If you must keep these features stay with PHP4, no big deal really.

Re:Backwards compatibility is very important (1)

unity100 (970058) | more than 6 years ago | (#23372516)

the catch is that, quite a many of the prominent scripts that are popular had been using some of those insecure features since some time ago, and there are a lot of people still using those old versions.

Re:Backwards compatibility is very important (0)

Anonymous Coward | more than 6 years ago | (#23372612)

Yes, but who in their right mind would blame php for breaking "many of the prominent scripts"? If widely used scripts are using idiotic constructs like magic quotes, I would herald the introduction of a new php version that will hopefully force these prominent scripts to be rewritten properly.

Re:Backwards compatibility is very important (1)

dmsuperman (1033704) | more than 6 years ago | (#23372442)

The magic of a new version: You don't have to upgrade. My company is still using PHP 4 on a couple servers, and will continue to do so until the clients decide they want to go with a full site upgrade which requires a rewrite.

Re:Backwards compatibility is very important (1)

fyoder (857358) | more than 6 years ago | (#23372734)

Where I work we have a couple of shared hosting servers which run two apaches, one for php4 and one for php5. It's a bit of a pita, but it works, and for us is easier than forcing clients at gunpoint to upgrade their php4 applications.

Unless there is a really compelling reason to add a third apache/php, I don't think we'll be quick to adopt this version. The better OO support in php5 made it something we wanted just for the stuff we write, but there doesn't seem to be much in php6 that is that exciting.

get_magic_quotes_gpc (1)

Dachannien (617929) | more than 6 years ago | (#23372014)

Removing the get_magic_quotes_gpc function altogether seems like the dumb way to handle backwards compatibility, breaking scripts for no good reason. Why not keep the function and just always have it return false?

False sense of correctness (0)

Anonymous Coward | more than 6 years ago | (#23372038)

If they just leave it, people will go on thinking things are good, until they're hacked. By throwing up a hard error, people will be aware there is a problem. If it's really such a problem, don't upgrade immediately, or write your own replacement function.

Re:get_magic_quotes_gpc (1)

eneville (745111) | more than 6 years ago | (#23372068)

Unfortunately a lot of people shove things into a PHP script in an ad-hoc manner. It's time the general people realise what their scripts are doing. I just wish people would pay attention to how mail() works...

Re:get_magic_quotes_gpc (1)

Dragonslicer (991472) | more than 6 years ago | (#23372070)

Removing the get_magic_quotes_gpc function altogether seems like the dumb way to handle backwards compatibility, breaking scripts for no good reason. Why not keep the function and just always have it return false?
I thought that's what they were doing. I know there was some discussion about it on the internals mailing list, but I thought sanity prevailed in that one.

Re:get_magic_quotes_gpc (1)

psyron (1175659) | more than 6 years ago | (#23372134)

I agree, it's just gonna make more work for people who check get_magic_quotes_gpc() to remove magic quotes in the first place.

Re:get_magic_quotes_gpc (1)

xSander (1227106) | more than 6 years ago | (#23372176)

Removing the get_magic_quotes_gpc function altogether seems like the dumb way to handle backwards compatibility, breaking scripts for no good reason. Why not keep the function and just always have it return false?
Because there should be a limit on what can be backwards compatible? magic_quotes_gpc is available in two major versions already, and PHP 6 won't be officially released anytime soon (as far as I know -- plus, upgrading to PHP 5 is going slowly.) Besides, PHP programming should be as independent as possible to PHP settings.

Too Little Too Late (-1, Flamebait)

Penguin Programmer (241752) | more than 6 years ago | (#23372112)

Unfortunately, everyone has already realized that PHP is an insecure, featureless piece of crap. Real web developers have moved onto other platforms, or stuck with Perl.

Re:Too Little Too Late (0)

Anonymous Coward | more than 6 years ago | (#23372170)

Absolutely. It's not like anyone still uses PHP [php.net] .

Re:Too Little Too Late (2, Insightful)

njcoder (657816) | more than 6 years ago | (#23372668)

Absolutely. It's not like anyone still uses PHP [php.net] .
Yeah. What happened in 2005 to make it plateau like that?

Re:Too Little Too Late (4, Insightful)

thetoadwarrior (1268702) | more than 6 years ago | (#23372264)

Um, no it's not. It's only downfall is that it's too easy to do powerful things so idiots make dangerous code.

That is not the language's fault. Not everyone wants or needs a JBoss server or something equally silly for their website. PHP is still very good. Safe programming in PHP just needs to be preached more to the new users of PHP and some of the self taught people who perhaps learned off the net from someone else with little experience rather than a book since all books I've seen cover the basics on safety.

The only thing that annoys me is the fact it's function naming methods aren't consistent. It shows that it's had input from various places without any thought into standardizing things.

Re:Too Little Too Late (3, Insightful)

FooAtWFU (699187) | more than 6 years ago | (#23372368)

That's not its only downfall. Its other downfalls include some miserable organization and bloated core, though much of this may be attributed to lack of namespace support - which is being remedied, but it's a bit late. There's still a lot of package_name_prefix_with_function_name functions, and I don't see them going away soon.

Beyond that, and the pervasive "make it easy to do the WRONG thing" un-philosophy, I still haven't heard about it getting lexical scope, closures, and anonymous functions. Of course, this only matters if you're a good programmer (as opposed to merely a Decently Adequate one).

Re:Too Little Too Late (1)

njcoder (657816) | more than 6 years ago | (#23372480)

Um, no it's not. It's only downfall is that it's too easy to do powerful things so idiots make dangerous code.
Most people don't write their own php scripts, they use what other's have written. And if one big vulnerability gets discovered in a script and you start seeing a bunch of websites getting defaced or worse. Most people are using some sort of shared hosting, so your site may get affected even if you don't have any php.

Since it takes less resources and performs better, most hosting companies run all php scripts as the same user. Yeah there are ways to jail it to a certain directory per user but that's not very secure. PHP's stance has pretty much been it shouldn't be the languages responsibility to come up with the security.

Re:Too Little Too Late (2, Insightful)

Falesh (1000255) | more than 6 years ago | (#23372316)

Don't be daft, PHP 5 is a solid language and it doesn't take much to learn how to write secure code. If you view it from a rookies point of view it could be dangerous, but that doesn't magically make the language crap in the hands of more experienced developers.

Re:Too Little Too Late (0)

Anonymous Coward | more than 6 years ago | (#23372428)

Don't be daft, PHP 5 is a solid language and it doesn't take much to learn how to write secure code. If you view it from a rookies point of view it could be dangerous, but that doesn't magically make the language crap in the hands of more experienced developers.

Don't be daft! [php-security.org] PHP is a poor language, I needed unsigned ints and native utf8 string handling 8 years ago. My problem is that much as I malign PHP and have tried all the alternatives, I've not really found anything better.


But the developers aren't really helping at this point. Why they can't sanely rename the inconsistent global functions and have a secondary alias table for backwards compat I'll never know.

Re:Too Little Too Late (1)

larry bagina (561269) | more than 6 years ago | (#23372558)

Would you really expect the same people that fucked up the language as bad as they did to suddenly fix it?

Re:Too Little Too Late (1)

zuperduperman (1206922) | more than 6 years ago | (#23372578)

> but that doesn't magically make the language crap in the hands of more experienced developers.

No, it makes the language total crap.

* In the hands of inexperienced developers, (it's primary user base), it's horrible because almost everything you do the default way is insecure.
* In the hands of experienced developers it's missing all kinds features that nearly any serious application needs.

The segment of people for which the language is not crap is really very small.

Re:Too Little Too Late (1)

Spatial (1235392) | more than 6 years ago | (#23372340)

As opposed to fake ones? [wikipedia.org]

Re:Too Little Too Late (0)

Anonymous Coward | more than 6 years ago | (#23372374)

You sir live in a dream world.

Re:Too Little Too Late (5, Insightful)

KnightMB (823876) | more than 6 years ago | (#23372496)

Unfortunately, everyone has already realized that PHP is an insecure, featureless piece of crap. Real web developers have moved onto other platforms, or stuck with Perl.
I think I hear this every time someone has been hurt by a buddy who was able to code circles around them in PHP while they struggled in Perl. Real web developers use every tool at their disposal, not just Perl or PHP only. Your statement alone shows the conceit you have about your own skills as compared to everyone else that makes a living doing web development, apparently much more successfully than you.

Magic Quotes was never a security function. (3, Insightful)

gandhi_2 (1108023) | more than 6 years ago | (#23372138)

It was to protect you from the O'Malleys and O'Connors. The PHP framers were obviously fans of Mel Brooks' film, Blazing Saddles: "We'll take the niggers and the chinks but we don't want the Irish". Or I'm missing something.

Real change (3, Insightful)

Anonymous Coward | more than 6 years ago | (#23372246)

Make it like a modern language.

Change . (string concat) to +

Change -> (pointer-to-member operator) to .

Done. Huge productivity increases.

Thank you.

Re:Real change (0)

Anonymous Coward | more than 6 years ago | (#23372488)

Change . (string concat) to +

And introduce typed variables? Or should they just make it like javascript where you have to multiply everything by 1 if you want to add a number to it?

Re:Real change (1)

Tablizer (95088) | more than 6 years ago | (#23372564)

Change . (string concat) to +

Nooooooo. That makes code confusing to read IMO.

Change -> (pointer-to-member operator) to .

Do what some other scriptish languages do: use "." for both objects and maps (associative arrays) because they are (or can be) pretty much the same thing. Then use something like "&" for strong concatenation.

I suppose nobody will agree on syntax matters.
   

Re:Real change (0)

Anonymous Coward | more than 6 years ago | (#23372634)

The perl argument against + is that 3 + 5 isn't different to 5 + 3 but "3" + "5" is different to "5" + "3". Perhaps they could use & instead of + then?

Re:Real change (0)

Anonymous Coward | more than 6 years ago | (#23372588)

They really should fix this C++-lineage. It makes for really ugly PHP code.

Re:Real change (0)

Anonymous Coward | more than 6 years ago | (#23372716)

Lineage implies it's a descendant language - it's not - it's a fabrication and a whole 'new' language with hints of many others.

Why PHP sucks (2, Informative)

rootpassbird (1276000) | more than 6 years ago | (#23372294)

They've fixed a lot of things that were being complained about under the terms "why php sucks" http://www.google.com/search?q=why+php+sucks [google.com] .
Related news is that PHP runs much better now on Windows Server 2008, as per the official Zend statement. But I doubt we will see too many people switch to WISP. This is flambait, agreed.
Also if you now have a PHP-fed brain with no place for anything else, with the new namespaces-on-steroids (http://www.php.net/manual/en/language.namespaces.using.php) change, you'll likely port slashcode to ::\/\.
And otherwise refer to <things like="this" /> :-)

Still a long way to go before it's fit for purpose (0)

Anonymous Coward | more than 6 years ago | (#23372388)

So, if you're a developer or architect using a different language, such as the Java programming language, because it has better internationalization (i18n) support than PHP, it'll be time to take another look at PHP when the support improves.

Err, no we're using Java because it's a coherently designed programming language and set of libraries, not just because it's got Unicode support throughout. At least they're removing som of the horrific hacks like "magic_quotes" and "register_globals".

what's with the 'phpsucks' tag? (5, Interesting)

sneakyimp (1161443) | more than 6 years ago | (#23372422)

I've noticed that every single article here mentioning PHP is immediately tagged 'phpsucks'. I find PHP incredibly expressive and am always surprised by the incredible variety of libraries/modules/plugins to manipulate graphics, flash, pdfs, to support protocols like SOAP, JSON, etc.

Perhaps we need an article on 'why php sucks' ?

Re:what's with the 'phpsucks' tag? (3, Interesting)

FooAtWFU (699187) | more than 6 years ago | (#23372506)

You mean like this? [www.tnx.nl]

It's not the lack of modules that people complain about. PHP is excessively convenient, if nothing else. :)

Re:what's with the 'phpsucks' tag? (0, Troll)

hardburn (141468) | more than 6 years ago | (#23372536)

People have written that article, and it's generally responded to by a lot of jumping up and down.

At this point, I'm content to leave PHP as a way to vacuum the dreck out of the Perl community.

Re:what's with the 'phpsucks' tag? (1, Funny)

Anonymous Coward | more than 6 years ago | (#23372728)

I find PHP incredibly expressive

You will benefit greatly from learning another language. Pretty much every modern language is more expressive than PHP. Even VBScript*.

* Little known fact: a lost appendix to the Bible mentions that VBScript is actually the fifth horseman of the apocalypse.

Short tags (0)

Anonymous Coward | more than 6 years ago | (#23372446)

Are short tags being removed, or deprecated? I remember reading that the devs had decided to leave short tags in.

No offence php, but <?php echo "Hi!"; ?> does not even *begin* to compare to <?= "Hi!"; ?>. Hiding behind "it breaks open xml tags", or that "default configuration has them disabled, so using them is not immediately portable across hosts" is bullshit. If I'm coding for my own environment, *I* will choose which format I use, and I should not be expected to use ugly syntax to make things "portable".

Re:Short tags (0)

Anonymous Coward | more than 6 years ago | (#23372700)

ONLY ASP Tags are being removed (<% %>)

New PHP features are great and all but.... (5, Interesting)

FilthCatcher (531259) | more than 6 years ago | (#23372534)

My biggest issue with new PHP changes is fact that the sheer size of the PHP libraries mean that these new features don't bubble through to the whole core.

For exmaple take the newish try / catch exception features. On first glance you think "finally I can write decent exception handling into my own code" - which is great for your own exceptions but too many of the core functions used by your code or by a framework you're using don't throw exceptions - they indicate an error codition in the function's result.

So now we're seeing loads of code out there by people trying to do things "The right way (tm)" but it's full of bugs as there's exception conditions being raised by core functions that don't get caught by the catch blocks.

The line from TFA that concerns me is "Much improved for PHP V6 is support for Unicode strings in many of the core functions"

Many? That will means developers will start using unicode only to find scattered lines of code throughout the app doesn't work as the core function it uses doesn't support unicode. The overhead of keeping track of which functions do and don't support unicode will be a nightmare.

IBM: Low quality as usual (1)

porneL (674499) | more than 6 years ago | (#23372758)

Apparently writing about PHP automatically allows using dumb code in examples:

function is_authorized() {
        if ($expression_that_returns_boolean) {
                return true;
        } else {
                return false;
        }
}

and

echo "Welcome, $_GET['cross_site_scripting_attack']!";

I guess PHP needs magic_entities ;)
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?