Pierre-Alain Joye picked this one up last week, and it needs repeating. For PHP6 the following are already gone from CVS:
Register globalsMagic quotesSafe mode
As blogged a while back, you’ll find these changes discussed here. Nice use of carrot and stick in fact – for the pain on fixing your apps to run under PHP6, you get Unicode.
Update: just noticed a new ini setting here;
allow_url_include “0″ PHP_INI_SYSTEM Available since PHP 6.0.0.
Excellent! That eliminates another major source of exploits (perhaps the biggest) – have moaned about that before here and here
Related posts:
- How to Install PHP 5.3 on Windows PHP 5.3 is the most significant update since version 5.0....
- How to Install PHP on Windows In his final installation tutorial, Craig provides a step-by-step guide...
- Who Won the Adobe Flex Builder 3 Prizes? Our recent Adobe-sponsored giveaway saw three copies of Flex Builder...
- Installing PHP on Windows Just Got Easier Have you ever felt frustrated when setting up a PHP/MySQL...
- Introducing php-tracer-weaver php-tracer-weaver is a tool for automatically generating docblock comments, with...
Good riddance to safe mode. The entire idea behind safe mode is sort of an acknowledgement of php’s shortcomings which need to be addressed (and evidently are in version 6).
March 10th, 2006 at 5:48 pm
I want to see namespaces as well. :)
I don’t use any of these anyways, so it doesn’t matter I guess.
March 10th, 2006 at 5:57 pm
I’m not up to date on the latest there but I got the impression namespaces could happen in PHP6 – see here.
March 10th, 2006 at 6:19 pm
I’d go as far as to say that if your code depends on these things now, you need to fix your apps.
S
March 10th, 2006 at 6:23 pm
> for the pain on fixing your apps to run under PHP6, you get Unicode
for unicode support, to get that finally in php anything is just about worth it i suppose…
March 10th, 2006 at 6:32 pm
Harry, whoever hasn’t already modified their app to not depend on register_globals and magic quotes should be beat with a professional stick, no doubt. It’s been a while since PHP 4.2.x.
March 10th, 2006 at 6:39 pm
Interesting. This means that they’re trowing away backward compatibility, which is a bold move; however, they still lack the courage — or wisdom — to finally divorce the two facets that is PHP: the Web development engine and the programming language. Instead, we’re getting their bastard child — the Zend Development framework — which reminds me of that story of a guy who lost his keys somewhere in the dark but searched for them under a lamp because there was more light.
March 10th, 2006 at 8:13 pm
What web development engine? Divorce how? AFAIK, PHP comprises two things: the Zend execution engine and the PHP language which includes all of the bundled core functions. What else can you be refering to? The fact that PHP is embeddable in documents (making it a “template” language)? I suppose not but essentially I don’t understand your comment, Berislav.
March 10th, 2006 at 9:36 pm
While I am in favour with most of the proposed changes, I totally disagree with the idea of making PHP more case-sensitive. My reasons are documented in
March 11th, 2006 at 6:38 am
3rd time lucky:
Case Sensitive Software is EVIL
March 11th, 2006 at 6:41 am
[...] In PHP6 zal dit niet meer mogelijk zijn, daarvoor is een nieuwe ini setting in het leven geroepen: allow_url_include. [via] [...]
March 11th, 2006 at 7:09 am
I see a large flood of other peoples remedial work coming my way soon, bring on the clients, daddy needs new shoes.
March 11th, 2006 at 7:34 am
My vote is for Tony marston. All your points are valid.
March 11th, 2006 at 11:09 am
What worries me is that if the transition to PHP 6 on inexpensive web hosts (which the majority of the millions of websites that use PHP happen to be running on) happens as slowly as the transition to PHP 5 (which is to say: not at all) then the advances in 6 will be practically futile. How do we get those web hosts and the makers of the web hosting software that they use (such as cPanel and Ensim and Plesk etc) to accelerate their updating of PHP?
March 11th, 2006 at 2:24 pm
In fact, I think it is such a serious issue that I will add this comment: I think the php community should immediately stop supporting version 4 altogether and move it to archival status. We’ll never get widespread movement to 5 or 6 otherwise. I worked for a few months last year for a fairly succssful web dev/hosting company that not only was still hosting customers on 4, it had left register_globals turned on because of a legacy shopping cart that one customer didn’t want to upgrade. Unbelievable! It shows what we’re up against in moving PHP forward in the wider world.
March 11th, 2006 at 2:35 pm
When will be PHP6 out
March 12th, 2006 at 2:19 am
Offtopic: I think case-sensitivity is a good thing in PHP. While we could argue till we a black and blue about why case-sensitivity is a bad thing in computers, it is standard practice in programming languages and PHP needs it to keep desired consitency. PHP should not be so brave to break the chains of cash-sensitive applications as it will only isolate itself from the programming community. It will not be respected as a programming langauge and ultimately will decline in popularity (from the people who we want to use it, anyhow). In a business sense it is important that PHP is case-senstive.
March 12th, 2006 at 8:28 pm
for all of you folks who are rubbing your hands waiting on the flood of clients… just sit tight.
The majority of web hosts don’t even offer PHP5 yet, and are all stuck on 4.3 (or even 4.23 with some hosts)…
Web hosts wont be doing anything that is going to cost their clients money or force them to another host…
so just sit tight.
March 12th, 2006 at 10:34 pm
Wow, it is going to be a seriously long time before we see PHP6 on shared web hosts.
March 13th, 2006 at 3:31 am
As an owner/operator of a shared hosting server, I empathise with the php4/5/6 debate. The main (only?) reason the likes of CPanel (cant speak for Ensim or Plesk) do not move to php5 is because the software they bundle like guestbooks, shopping carts, etc do not run under php5. Just to get our systems up to php5, I’m actually pushing for our servers to drop support for those bundled scripts. Due to the relatively low numbers of clients on some of the sytems, I’m even willing to donate my time (within reason) to those clients that have problems upgrading, just I can personally use the “new” features in my own projects.
March 13th, 2006 at 4:36 am
[...] Rails is parsing the HTTP Accept header at a very high level, abstracting away the often hacky details from the business logic, whilst PHP6 is dropping features like Microsoft approaching a deadline, although in this case the revolutionary news is that register globals is gone. I’m not sure how you’ll be able to swing an upgrade to PHP6 past the proverbial pointy-haired middle management types though. Telling them that safe mode has been dropped as a reason to upgrade is just going to lead to a lot of confusion. [...]
March 13th, 2006 at 6:42 am
Well, yes, that’s one thing, but I’m also referring to all the bits and pieces that make sense only in Web development environment: register_globals, sessions, cookies, various Web-related enviroment values (e.g. $_SERVER) etc. For PHP to be a “fully-fledged” language it needs to be employable without them; also, although it can be a CLI-only scripting language, I would like to see an implementation of PHP5 that could persist objects in memory, perhaps an extension-based GUI library etc…
On a related note, since we talk about breaking backward compatibility, here’s an idea that seems so natural to me, and I’ve seen no language employing it — it would be a perfect fit for PHP. Instead of using a ‘.’ for string concatenation, it would be interesting to use whitespace for that purpose. E.g., any variables or literals following each other would be converted into string:
$my_string = $my 'new' ' ' $variableName 225 334 'goes here' isntit();A nice side-effect of that would be that it would free ‘.’ for other uses — for example namespaces.
March 13th, 2006 at 8:14 am
Introducing more case-sensitivity just to be consistent with other languages is a pathetic argument. Case sensitivity causes more problems than it solves, so it should be removed in the name of comon sense.
The millons of existing PHP programmers do NOT see the lack of case sensitivity as a problem, and those non-PHP programmers who refuse to touch it because of this are, quite frankly, people whom the PHP community would be better off without.
Absolute rubbish! People who use applications do not care whether the language it was written in is case sensitive or not. It is a matter only for programmers, not business users.
March 13th, 2006 at 9:40 am
well tony, when making a case sensitivity arguement, next time, use C# not vb, vb is generally not case sensitive. (in fact my employer programs in vb for this reason, because its generally not case sensitive). http://www.tonymarston.net/php-mysql/case-sensitive-software-is-evil.html
however case sensitivity does has it uses for those of us who program a certain way and would like functions, methods and such to be typed consistently through out the code base. I think code consistency helps with readability and is extremely important as readability helps code to be somewhat self documenting.
i know that in c# i generally use hungarian notation for fields and and then Uppercase the first letter of properties. while this currently does not apply to php, it may in the future should they php group/ zend provide property accessors and perhaps do away with $ for fields/vars in the class scope.
however i sympathize if you want to be lazy and not worry about case sensitivity ;)
March 13th, 2006 at 1:19 pm
oh yeah if you’re making long variables like this …avariablelikethisisveryhardtounderstand….tisk tisk, bad example
March 13th, 2006 at 1:21 pm
PHP was intentionally designed for use on the Web, that’s what’s unique about it. The fact that it streamlines such tasks as grabbing the query string key/value pairs is not a hindrance as a language. If we follow your prerequisites, then we should all just use Perl (a great language, btw).
Aren’t you referring to PHP-GTK?
March 14th, 2006 at 4:51 am
Oh my god, I can not believe the arguments people are trying to make against the article written by Tony regarding the case sensitivity.
How can this be a bad example? You should think first, then write. Just because a language is case insensitive doesn’t mean you can not use camelcaps (btw. I personally disagree with Tony’s statement that camelcaps are stupid, but that’s just a matter of preference, and if you know that Tony is in the business for so long it doesn’t come as a suprise that he favours _ over camelcaps).
Enforcing a language to be case sensitive JUST to ensure the code is readable is a very pathetic argument indeed, and don’t even get me started about the person who said it’s important for business (omg!!!)
While most of the time I disagree with Tony’s oppinion on a lot of matters, I have to agree with him on this one issue.
I would really like to know why the PHP dev’s are even considering this.
I’d rather like them to put all that energy into making sure UTF-8 will work flawless ;)
March 14th, 2006 at 7:25 pm
Any way you slice it, case-sensitivity is a matter of personal preference. Having case-sensitivity provides a more versatile language, and the consistency IS important. Most RDBMS’ are built case-sensitive, and with good reasons. Most PHP apps connect to an RDBMS. It makes good sense to maintain structure and standards across the two. Just my two cents. Feel free to flame me as lame as you have the others. Frankly I haven’t read any contrary responses I didn’t feel the same way about. As I said to begin with, it’s all a matter of preference.
As for PHP 6, good riddance to the lot of the dropped “features”.
March 15th, 2006 at 10:51 am
If it is a matter of personal preference then why should should anybody’s personal preferences be forced upon others?
How so? All I see is the potential to create confusing code where variables such as $account and $Account point to different things, and functions such as dostuff() and DoStuff() mean different things. If the IDE/compiler of the language can detect differences in case and automatically synchronise them to compensate then case-sensitivity becomes transparent, but PHP does not have this capability, so the potential for writing bad code is only increased by introducing case-sensitivity.
Introducing something “to be consistent” is a totally dumb idea if what you are perpetuating is a mechanism for creating confusing code.
Rubbish! I have never come across ay RDBMS which is case-sensitive! When you write an SQL query you can use any mixture of case for database names, table names, column names and function names. This makes them insensitive to case.
March 15th, 2006 at 11:42 am
@datune i was talking about the length of the variable.
first off not everyone uses an IDE with php, so yes the variables should be readable, but not overly long, because some people code by hand without any kind of intellisence and the longer the variable, the more of a chance there is to copy only a part or mistype the variable.
please lay off the “omg”, it could be considered insulting.
if $firstName or $first_name or $firstname is how you want to type it, then go ahead, however it should be the same throughout the code base.
i’m sure when php6 comes out, the Eclipse IDE plugin or whatever they are making in conjuction with Eclipse for the new zend framework will handle the case sensitivity issue.
besides if you coded consistenly in the first place, this wouldn’t be that big of an issue.
March 15th, 2006 at 2:40 pm
I’m not a programmer, but I get the feeling that PHP is adopting case sensitivity just so it can comply with other languages, rather than if it makes programming sense per say?
March 23rd, 2006 at 9:13 am
PHP is an interpreted laguage.
For computers “thisstring” != “ThisString”, ‘a’ != ‘A’.
You would need to lowercase (or uppercase) all calls to methods/functions/variables in a case-insensitive system.
That would be slower. Slower is bad.
May 19th, 2007 at 6:23 am