Slashdot Mirror

I asked this question last time and no one answered. Where are the docs for this FFI thing? The only thing I could find was some unmaintained deprecated precursor pcre external. No docs there either.

The announcement doesn't even list it.

Where the hell are all these reporters getting this information from if not from the announcement and there are no docs?

Bueller?

Yep, no clear answers yet.

PHP 7 deprecated some more functions, broke a few things, added the spaceship operator, but apart from that it's basically the same. That page still applies.

http://php.net/manual/en/migra...

since PHP 5.x is supported and will have security patches, why would we bother to even test 7.x

I thought it was obvious, and you knew, but here it is:

PHP 5.6 (the last release for 5.x) will be end of life by 31 Dec 2018 (that is 2 months from now).

PHP 7.0, which is the default version for Ubuntu 16.04 LTS, end of life 3 Dec 2018 (1 month from now).

See PHP supported versions.

Hence, PHP 7.2 is the current version with the most life left, and the need to upgrade to it.

A little more into the future: PHP 7.3 is still RC, but the good news is that there is not much difference between it and 7.2, therefore the upgrade from 7.2 to 7.3 should painless.

> PHP was the insane choice

FTFY.

PHP is shit.

The online manual is crap as well. Searching for true, TRUE, false, FALSE, all return:

X doesn't exist. Closest matches:

*facepalm*

Why do two of shittiest programming languages around, PHP and JavaScript, drive much of the Web?

*double facepalm*

> PHP was the insane choice

FTFY.

PHP is shit.

The online manual is crap as well. Searching for true, TRUE, false, FALSE, all return:

X doesn't exist. Closest matches:

*facepalm*

Why do two of shittiest programming languages around, PHP and JavaScript, drive much of the Web?

*double facepalm*

> PHP was the insane choice

FTFY.

PHP is shit.

The online manual is crap as well. Searching for true, TRUE, false, FALSE, all return:

X doesn't exist. Closest matches:

*facepalm*

Why do two of shittiest programming languages around, PHP and JavaScript, drive much of the Web?

*double facepalm*

> PHP was the insane choice

FTFY.

PHP is shit.

The online manual is crap as well. Searching for true, TRUE, false, FALSE, all return:

X doesn't exist. Closest matches:

*facepalm*

Why do two of shittiest programming languages around, PHP and JavaScript, drive much of the Web?

*double facepalm*

I would expect a simple update guide with breaking changes and simple resolutions.

Expected it, got it. Google Search for php 7.0 breaking changes returned this section of the official migration guide as the first result.

There's little to no difference between python and php that isn't purely syntactical.

And there are places where syntax makes all the difference, such as list comprehensions (and the generator expressions that power them).

all the criticisms against php are equally valid against python.

I've found a few, which I'll quote here for convenience:

• Number-like comparison of strings can never be fully turned off. For example, both '10' <= '1e1' and '10' >= '1e1'. One can use strcmp in one's own code and pass sort_flags to sorting functions that support them, but some functions still use the built-in operators < and > that don't even impose a total order. Likewise, switch uses the built-in == comparison operator whose semantics are byzantine.
• Parse errors and undefined function errors are fatal in PHP 5. (Or do CentOS and RHEL have PHP 7 packages yet?)
• Inconsistent conventions for function naming and argument order in the standard library.
• Associativity for the ternary ?: operator is the less useful side.
• PHP allows the server operator to change program semantics in ways that are annoying to work around, especially for shared hosting subscribers without access to the server-wide configuration. At various times, these have included "magic quotes" that spray backslashes all over the request variables, not following HTTP redirects in the CURL library,[1] and restricting the size of files uploaded by a site's users to outdated limits such as 2 megabytes by default.
• PHP versions change the semantics of existing programs in ways that encourage shared hosting providers to continue to offer only outdated versions of PHP, making it impossible for web application developers to take advantage of new features. Compare Python, which puts added functions in one namespace per module and conditions new incompatible syntax features on presence of from __future__ statements.
• The developers of PHP rejected keyword arguments.

[1] From March 2005 through September 2013, cURL could not follow redirects with open_basedir enabled because of a heavy-handed security fix.

There's little to no difference between python and php that isn't purely syntactical.

And there are places where syntax makes all the difference, such as list comprehensions (and the generator expressions that power them).

all the criticisms against php are equally valid against python.

I've found a few, which I'll quote here for convenience:

• Number-like comparison of strings can never be fully turned off. For example, both '10' <= '1e1' and '10' >= '1e1'. One can use strcmp in one's own code and pass sort_flags to sorting functions that support them, but some functions still use the built-in operators < and > that don't even impose a total order. Likewise, switch uses the built-in == comparison operator whose semantics are byzantine.
• Parse errors and undefined function errors are fatal in PHP 5. (Or do CentOS and RHEL have PHP 7 packages yet?)
• Inconsistent conventions for function naming and argument order in the standard library.
• Associativity for the ternary ?: operator is the less useful side.
• PHP allows the server operator to change program semantics in ways that are annoying to work around, especially for shared hosting subscribers without access to the server-wide configuration. At various times, these have included "magic quotes" that spray backslashes all over the request variables, not following HTTP redirects in the CURL library,[1] and restricting the size of files uploaded by a site's users to outdated limits such as 2 megabytes by default.
• PHP versions change the semantics of existing programs in ways that encourage shared hosting providers to continue to offer only outdated versions of PHP, making it impossible for web application developers to take advantage of new features. Compare Python, which puts added functions in one namespace per module and conditions new incompatible syntax features on presence of from __future__ statements.
• The developers of PHP rejected keyword arguments.

[1] From March 2005 through September 2013, cURL could not follow redirects with open_basedir enabled because of a heavy-handed security fix.

There's little to no difference between python and php that isn't purely syntactical.

And there are places where syntax makes all the difference, such as list comprehensions (and the generator expressions that power them).

all the criticisms against php are equally valid against python.

I've found a few, which I'll quote here for convenience:

• Number-like comparison of strings can never be fully turned off. For example, both '10' <= '1e1' and '10' >= '1e1'. One can use strcmp in one's own code and pass sort_flags to sorting functions that support them, but some functions still use the built-in operators < and > that don't even impose a total order. Likewise, switch uses the built-in == comparison operator whose semantics are byzantine.
• Parse errors and undefined function errors are fatal in PHP 5. (Or do CentOS and RHEL have PHP 7 packages yet?)
• Inconsistent conventions for function naming and argument order in the standard library.
• Associativity for the ternary ?: operator is the less useful side.
• PHP allows the server operator to change program semantics in ways that are annoying to work around, especially for shared hosting subscribers without access to the server-wide configuration. At various times, these have included "magic quotes" that spray backslashes all over the request variables, not following HTTP redirects in the CURL library,[1] and restricting the size of files uploaded by a site's users to outdated limits such as 2 megabytes by default.
• PHP versions change the semantics of existing programs in ways that encourage shared hosting providers to continue to offer only outdated versions of PHP, making it impossible for web application developers to take advantage of new features. Compare Python, which puts added functions in one namespace per module and conditions new incompatible syntax features on presence of from __future__ statements.
• The developers of PHP rejected keyword arguments.

[1] From March 2005 through September 2013, cURL could not follow redirects with open_basedir enabled because of a heavy-handed security fix.

There's little to no difference between python and php that isn't purely syntactical.

And there are places where syntax makes all the difference, such as list comprehensions (and the generator expressions that power them).

all the criticisms against php are equally valid against python.

I've found a few, which I'll quote here for convenience:

• Number-like comparison of strings can never be fully turned off. For example, both '10' <= '1e1' and '10' >= '1e1'. One can use strcmp in one's own code and pass sort_flags to sorting functions that support them, but some functions still use the built-in operators < and > that don't even impose a total order. Likewise, switch uses the built-in == comparison operator whose semantics are byzantine.
• Parse errors and undefined function errors are fatal in PHP 5. (Or do CentOS and RHEL have PHP 7 packages yet?)
• Inconsistent conventions for function naming and argument order in the standard library.
• Associativity for the ternary ?: operator is the less useful side.
• PHP allows the server operator to change program semantics in ways that are annoying to work around, especially for shared hosting subscribers without access to the server-wide configuration. At various times, these have included "magic quotes" that spray backslashes all over the request variables, not following HTTP redirects in the CURL library,[1] and restricting the size of files uploaded by a site's users to outdated limits such as 2 megabytes by default.
• PHP versions change the semantics of existing programs in ways that encourage shared hosting providers to continue to offer only outdated versions of PHP, making it impossible for web application developers to take advantage of new features. Compare Python, which puts added functions in one namespace per module and conditions new incompatible syntax features on presence of from __future__ statements.
• The developers of PHP rejected keyword arguments.

[1] From March 2005 through September 2013, cURL could not follow redirects with open_basedir enabled because of a heavy-handed security fix.

PHP, itself, is a crappy language. It relies on a massive, accreted standard library, and has only fairly recently become halfway acceptable as an object-oriented language.

It's filled with stuff like this: array_map($callback, $array) vs. array_walk(&$array, $callback) (with the array being changed by reference in the second).

That's what happens when you have a million monkeys on a million typewriters.

That said, it's here to stay for a long time, and is a VERY powerful and well-supported server language. It's one of Facebook's principal languages, and they have contributed to it in a big way. It's quite legitimate as a business choice for server support. It has a ginormous support community, and millions of articles and recipes.

There's any number of languages that are much more elegant, and, depending on the application, appropriate, but you need to realize that sloppy programmers will create garbage in any language.

There's this "cargo cult" mentality in software development, these days, where people think that the tools make the software, so they get whatever shiny tool is hot right now, and throw it into a room with a million low-cost monkeys, and wait for the collected works of Shakespeare to emerge.

Languages like PHP and C++ are constantly being slagged by hipsters, these days, but they keep going, and still power some of the most important infrastructure on Earth; usually because the people writing code in them are very good.

Linux is still pretty much all C. Not C++, not C#, not Objective-C. C.

That's because Linus is not a monkey, despite his penchant for sometimes throwing poop. He's a damn good architect and engineer. That don't come from a Cracker Jack box.

If you are a monkey, then I suggest making sure that your fundamentals, like design ethos, ethics, quality, and structural discipline are in good shape. These will translate to any tool that you use, and allow you to choose the most useful, business-relevant tool to use for a given application.

A new banana won't help.

PHP, itself, is a crappy language. It relies on a massive, accreted standard library, and has only fairly recently become halfway acceptable as an object-oriented language.

It's filled with stuff like this: array_map($callback, $array) vs. array_walk(&$array, $callback) (with the array being changed by reference in the second).

That's what happens when you have a million monkeys on a million typewriters.

That said, it's here to stay for a long time, and is a VERY powerful and well-supported server language. It's one of Facebook's principal languages, and they have contributed to it in a big way. It's quite legitimate as a business choice for server support. It has a ginormous support community, and millions of articles and recipes.

There's any number of languages that are much more elegant, and, depending on the application, appropriate, but you need to realize that sloppy programmers will create garbage in any language.

There's this "cargo cult" mentality in software development, these days, where people think that the tools make the software, so they get whatever shiny tool is hot right now, and throw it into a room with a million low-cost monkeys, and wait for the collected works of Shakespeare to emerge.

Languages like PHP and C++ are constantly being slagged by hipsters, these days, but they keep going, and still power some of the most important infrastructure on Earth; usually because the people writing code in them are very good.

Linux is still pretty much all C. Not C++, not C#, not Objective-C. C.

That's because Linus is not a monkey, despite his penchant for sometimes throwing poop. He's a damn good architect and engineer. That don't come from a Cracker Jack box.

If you are a monkey, then I suggest making sure that your fundamentals, like design ethos, ethics, quality, and structural discipline are in good shape. These will translate to any tool that you use, and allow you to choose the most useful, business-relevant tool to use for a given application.

A new banana won't help.

maybe they are better at spotting a whole different author identity

Good luck with that, as email addresses and author usernames can also be typosquatted, and unless you have the resources of Facebook to bruteforce a hash, key IDs aren't going to be as memorable as "boobies" or "dead beef".

installing urllib, signed by 0xb00b1e5 'original@outlook.com'
# vs.
installing urlib, signed by 0xdeadbeef 'origina1@outlook.com'

I'm more of a Perl guy than Python guy [...] but if the most common non-core modules are developed by a few known authors

Does CPAN have the same situation where "common non-core modules are developed by a few known authors"?

Yet another way to use cryptography, would be to take notice from GPG's web of trust

I imagine OpenPGP's web of trust would have two significant practical problems.

or from PKI's root certificates

Members of the CA/Browser Forum PKI will happily sign a domain-validated certificate for a typosquatted domain.

it could also be useful that pypi.org refuse to automatically open new modules repositories for modules whose name isn't beyond a certain levenstein distance of other name present

This raises an exception I found to Python's batteries-included philosophy: Levenshtein distance comes with one of Python's major competitors, but it's behind an third-party module in Python.

It's not like every question on stackoverflow is unique. There are plenty of sites in other languages with plenty of code snippets. The official french PHP documentation, also available in 9 other languages. You can find french versions for most programming languages, including c++ and java, just by searching $PROGRAMMING_LANGUAGE_OF_CHOICE examplaires . Or you can substitute the word "examplaires" for the the translation of the term "example" in the written language of your choice.

atoi()? Whatever your little heart and your imagination desires. For example, overload entier() to take strings in a header, and then a simple text substitution of atoi() to entier(). Or if you like conciseness, ent. 25% fewer letters than atoi.

An add-on crypto library compiled to native code and distributed as a PHP extension

use an add on binary library that runs at full speed but that the user can install together with their scripts through dynamic loading

That depends on two things: whether the shared hosting provider has configured the interpreter to allow such dynamic loading, particularly from within the subscriber's home directory, and whether the shared hosting provider allows the subscriber to install a compiler and corresponding headers to compile said library. As the PHP manual states:

The main reason for turning dynamic loading off is security. With dynamic loading, it's possible to ignore all open_basedir restrictions.

No, PHP support two kinds of strings, incompatible with each other. There is even a comment on the official documentation for strcmp: http://php.net/manual/en/funct...

You are wrong. In my example, using ==, it will report equal. Using ===, it will report not equal.

$ php -r "if (\"0E54321\" === \"0E12345\") { echo \"equal\n\"; } else { echo \"not equal\n\"; } "
not equal
$ php -r "if (\"0E54321\" == \"0E12345\") { echo \"equal\n\"; } else { echo \"not equal\n\"; } "
equal

The string "0E54321" and "0E12345" both get converted into the integer 0 for comparison purposes when you only use ==.

The documentation clearly explains this behavior. I'll link it again for you.
Type Juggling
String Conversion

You are wrong. In my example, using ==, it will report equal. Using ===, it will report not equal.

$ php -r "if (\"0E54321\" === \"0E12345\") { echo \"equal\n\"; } else { echo \"not equal\n\"; } "
not equal
$ php -r "if (\"0E54321\" == \"0E12345\") { echo \"equal\n\"; } else { echo \"not equal\n\"; } "
equal

The string "0E54321" and "0E12345" both get converted into the integer 0 for comparison purposes when you only use ==.

The documentation clearly explains this behavior. I'll link it again for you.
Type Juggling
String Conversion

Agreed. The problem is not the library - PHP is intrinsically insecure. I'm not aware of any other language out there that can reliably be made to segfault and whose developers argue such behavior is working as intended.

If you're quoting bug reports from 2009 to back up anything you say, then you're falling into the standard trap of knowing that PHP was bad but believing that nothing has changed in the last decade.

Things have moved on.

Yes, it still has some quirks, but it is not the same language that you hated ten years ago. Virtually all of the big issues that people had with the language have been dealt with.

Agreed. The problem is not the library - PHP is intrinsically insecure. I'm not aware of any other language out there that can reliably be made to segfault and whose developers argue such behavior is working as intended.

PHP has a comparison operator === that evaluates if the two things it is comparing are equal and of the same type.

$ php -r "if (\"0E54321\" === \"0E12345\") { echo 'equal'; } else { echo 'not equal'; } "
not equal

Without ===, variable type conversion can cause a string containing numbers to be converted to an integer. See these links for details:

http://php.net/manual/en/langu...
http://php.net/manual/en/langu...

PHP has a comparison operator === that evaluates if the two things it is comparing are equal and of the same type.

$ php -r "if (\"0E54321\" === \"0E12345\") { echo 'equal'; } else { echo 'not equal'; } "
not equal

Without ===, variable type conversion can cause a string containing numbers to be converted to an integer. See these links for details:

http://php.net/manual/en/langu...
http://php.net/manual/en/langu...

The expectation of PHP's behaviour in your example is clearly documented. Like everything if you RTFM it works as described. If you are coding PHP you would know this behaviour. The consequence in your example is born from a programmer having an expectation that all languages are alike, which they are not. This is a user error not a language problem.

The expectation of PHP's behaviour in your example is clearly documented. Like everything if you RTFM it works as described. If you are coding PHP you would know this behaviour. The consequence in your example is born from a programmer having an expectation that all languages are alike, which they are not. This is a user error not a language problem.

PHP doesn't need Apache anymore. It's had a standalone web server for years now.

http://php.net/manual/en/features.commandline.webserver.php

I run a single page web app this way. It's actually rock solid.

Node.js is overrated.

> Wait... the PHP interpreter doesn't tell you this?

Of course it does. It issues a warning at level E_DEPRECATED. The manual answers your question here:

http://php.net/manual/en/error...
And here:
http://php.net/manual/en/error...

As noted in the manual, you not want a log entry every time a someone runs a script which includes a deprecated function; that could be a million times per day, if you have a million visitors. Like most languages, you'll want to set the reporting level higher during development, to see all the notices, then lower on production so you're not spammed by warning you've chosen to disregard.

> Wait... the PHP interpreter doesn't tell you this?

Of course it does. It issues a warning at level E_DEPRECATED. The manual answers your question here:

http://php.net/manual/en/error...
And here:
http://php.net/manual/en/error...

As noted in the manual, you not want a log entry every time a someone runs a script which includes a deprecated function; that could be a million times per day, if you have a million visitors. Like most languages, you'll want to set the reporting level higher during development, to see all the notices, then lower on production so you're not spammed by warning you've chosen to disregard.

Unless I'm mis-reading your post, you've brought up three different issues:

a) What is the best way to update a PHP script?
b) How do Wordpress and Drupal update by default?
c) How do you update the PHP interpreter without breaking scripts?

> a) What is the best way to update a PHP script?

Probably the best way is to use a revision control system such as "git", "cvs", "svn", or "hg". You can look at the Wordpress SVN here:

https://core.trac.wordpress.or...

The system tracks all changes:
https://core.trac.wordpress.or...

On an up-to-date server, you can run "svn update" to retrieve all of the updates that you're missing. An an older system, you can pull only the specific changes you want, such as security patches:
https://core.trac.wordpress.or...

b) How do Wordpress and Drupal update by default?

In a stupid way. The script itself downloads the new version from the Wordpress web site. For this to work, the script (and therefore all scripts on the server) needs to have permission to overwrite files on the server. That's bad because in most cases that means *any* script can change *any* file on the site. Any little security hole in any script allows the bad guy to write whatever he wants, including his own software, and run it on your server. That's a bad idea. It's *possible* to set this up to be reasonably secure, but nobody does. PHP makes the more secure configuration much more difficult than it needs to be.

> c) How do you update the PHP interpreter without breaking scripts?

Most of the time, a function will be deprecated several years before it's removed or disabled by default. Use http://php.net/manual/ to understand the PHP you're writing rather than copying and pasting shit from Stackoverflow that might have been halfway correct six years ago. The manual will let you know if a function is deprecated, and point to the newer approach you should use instead. Aside from using good documentation (not forums) as your primary learning tool and avoiding deprecated functions, you can make your software easier to update and fix later. That's mostly about modularity - keep unrelated things separate. Ideally each function you write would be no longer than about 4-12 lines. A simple, short function is easier to update later. Related functions can be group into classes ( http://php.net/manual/en/langu... ). It's much easier to fix your file uploader if it's all together in a file called "fileuploader.php" rather than being sprayed through "mega_forum_script.php" (8MB).

> *super novice programmer here* ... PHP

You have a much harder road ahead of you than us oldtimers who learned in the 1980s and 1990s. Your newbie code will be exposed in the internet, where it'll be attacked several times per hour. That's very high risk. Minimize your exposure by trying to avoid working with confidential data for now. Recognize your limitations and don't try to write a security system or shopping cart with credit card payments right now. When you *do* have to work on something that could cause damage when attacked, consider asking a programmer who is trained in security to do code review. (I've been programming professionally for 20 years, mostly doing security-related code, and I still ask my peers to review my work - there's no shame in that.)

Unless I'm mis-reading your post, you've brought up three different issues:

a) What is the best way to update a PHP script?
b) How do Wordpress and Drupal update by default?
c) How do you update the PHP interpreter without breaking scripts?

> a) What is the best way to update a PHP script?

Probably the best way is to use a revision control system such as "git", "cvs", "svn", or "hg". You can look at the Wordpress SVN here:

https://core.trac.wordpress.or...

The system tracks all changes:
https://core.trac.wordpress.or...

On an up-to-date server, you can run "svn update" to retrieve all of the updates that you're missing. An an older system, you can pull only the specific changes you want, such as security patches:
https://core.trac.wordpress.or...

b) How do Wordpress and Drupal update by default?

In a stupid way. The script itself downloads the new version from the Wordpress web site. For this to work, the script (and therefore all scripts on the server) needs to have permission to overwrite files on the server. That's bad because in most cases that means *any* script can change *any* file on the site. Any little security hole in any script allows the bad guy to write whatever he wants, including his own software, and run it on your server. That's a bad idea. It's *possible* to set this up to be reasonably secure, but nobody does. PHP makes the more secure configuration much more difficult than it needs to be.

> c) How do you update the PHP interpreter without breaking scripts?

Most of the time, a function will be deprecated several years before it's removed or disabled by default. Use http://php.net/manual/ to understand the PHP you're writing rather than copying and pasting shit from Stackoverflow that might have been halfway correct six years ago. The manual will let you know if a function is deprecated, and point to the newer approach you should use instead. Aside from using good documentation (not forums) as your primary learning tool and avoiding deprecated functions, you can make your software easier to update and fix later. That's mostly about modularity - keep unrelated things separate. Ideally each function you write would be no longer than about 4-12 lines. A simple, short function is easier to update later. Related functions can be group into classes ( http://php.net/manual/en/langu... ). It's much easier to fix your file uploader if it's all together in a file called "fileuploader.php" rather than being sprayed through "mega_forum_script.php" (8MB).

> *super novice programmer here* ... PHP

You have a much harder road ahead of you than us oldtimers who learned in the 1980s and 1990s. Your newbie code will be exposed in the internet, where it'll be attacked several times per hour. That's very high risk. Minimize your exposure by trying to avoid working with confidential data for now. Recognize your limitations and don't try to write a security system or shopping cart with credit card payments right now. When you *do* have to work on something that could cause damage when attacked, consider asking a programmer who is trained in security to do code review. (I've been programming professionally for 20 years, mostly doing security-related code, and I still ask my peers to review my work - there's no shame in that.)

PHP doesn't require you to declare variables.

Neither does Python. But both languages will warn you when you try to read a variable that you haven't already written. Python raises an exception, and PHP raises a warning, which (under best practices) gets converted into an exception.

If you're hired to help fix someone's website and it's written in PHP, you gotta write your fix in PHP.

That or transpile the entire project into a different language.

You might be tempted to code the fix in a better language and have the PHP script call it, but that destroys the maintainability of the code for future programmers.

Not if "future programmers" understand the language into which you have transpiled the project. It might even be cheaper to hire "future programmers" who understand the language into which you have transpiled the project than to clean up after programmers who fail to avoid PHP gotchas.

PHP is almost exclusively used on Linux and is restricted to web development

What a crock of shit. Both PHP and JavaScript can be used in non web development. Just not many people do because there are other more established/efficient ways. But can you do it? Yes. Should you do it? Up to you. Enjoy the freedom to do whatever the fuck you want with whatever language you want, even if it doesn't make sense. If you are having fun who cares. If you have to work with a bunch of people use what you all know that gets the job done the easiest. Everything else is just pissing into the wind, making it difficult for yourself and everyone else standing behind you.

I'm aware of all of this. I started developing web applications around 1998.

I use ImageMagick because in my testing it was faster at the time for bicubic resizing/scaling. I'm using the Imagick PECL extension, which mostly eliminates the security and speed issues as it wraps the library into a PHP extension. I've written it to never scale an image up. If you specify a height and width larger than the original file, you'll be served the original file... So someone smart enough can't fiddle and blow up images wasting server resources.

The point of having it dynamic is that I don't have to go out of my why (which interrupts my workflow) to fire up a graphics editor and make multiple scaled versions of an image. That, and 95% of the time the websites are operated and managed by whomever I create them for. Having a way to scale images for technically inept clients (that don't understand what a pixel is, let alone how you need to scale down pictures from your Canon camera before putting them on the web) is a huge time saver.

They inject code right into the script that already has the execute bit set. It's not uncommon, I've seen it myself.

Looking at this specific example, WP Mobile Detector flaw, I can't see how that would be possible.

Just to recap (mostly for my own benefit to make sure I'm not going mad!), this flaw works by sending a URL to a vulnerable website. The vulnerable website then uses file_get_contents() to read the file... it is assuming the file is local, but actually it's a URL to somewhere else. If the server is configured with allow_url_fopen then file_get_contents() will perform the necessary HTTP GET to retrieve the contents of that file. The file still needs to be written to disk, which in this case is performed by file_put_contents().

None of the above is going to set the execute bit.

They inject code right into the script that already has the execute bit set. It's not uncommon, I've seen it myself.

Looking at this specific example, WP Mobile Detector flaw, I can't see how that would be possible.

Just to recap (mostly for my own benefit to make sure I'm not going mad!), this flaw works by sending a URL to a vulnerable website. The vulnerable website then uses file_get_contents() to read the file... it is assuming the file is local, but actually it's a URL to somewhere else. If the server is configured with allow_url_fopen then file_get_contents() will perform the necessary HTTP GET to retrieve the contents of that file. The file still needs to be written to disk, which in this case is performed by file_put_contents().

None of the above is going to set the execute bit.

They inject code right into the script that already has the execute bit set. It's not uncommon, I've seen it myself.

Looking at this specific example, WP Mobile Detector flaw, I can't see how that would be possible.

Just to recap (mostly for my own benefit to make sure I'm not going mad!), this flaw works by sending a URL to a vulnerable website. The vulnerable website then uses file_get_contents() to read the file... it is assuming the file is local, but actually it's a URL to somewhere else. If the server is configured with allow_url_fopen then file_get_contents() will perform the necessary HTTP GET to retrieve the contents of that file. The file still needs to be written to disk, which in this case is performed by file_put_contents().

None of the above is going to set the execute bit.

Does it mean my webpage won't either die with no error or run fine with unhelpful warnings anymore?

If you want exception semantics instead of "error reporting", use ErrorException .

‘old PHP’ – That is false. The same security bug still exists in PHP 7.0.6, and worse still, it isn't called out in the documentation at all. I cannot understand how people can be so irresponsible.
As I said before, it is possible to work around it, but PHP was meant to be for the web and for novice developers. The fact that you can work around it, with a call to array_values or by coding the loop differently or by using a hopefully bug-free ORM that hides the SQL from you altogether and hoping you'll never have to iterate over an array yourself, therefore means very little, especially since the official documentation itself makes no mention of this issue.
How exactly is a novice programmer supposed to know that this security bug exists? How is someone reviewing the code who hasn't been warned about the issue beforehand supposed to catch that foreach may not do what you think it does, especially when he's a novice or hasn't got as much time as he'd like?
This issue manifested in a major CMS. If they cannot do it right, it's unreasonable to expect most PHP programmers to get it right anyway.

RTFM

+ http://php.net/manual/en/langu...
+ http://php.net/manual/en/funct...

RTFM

+ http://php.net/manual/en/langu...
+ http://php.net/manual/en/funct...

My first thought was that the language (be it Javascript or PHP) is too dynamic or weakly typed and converts a "NULL" string to a NULL type or value. But I tested for that : $a=("NULL" == NULL); and thanksfully that's false.
Interestingly, in PHP the NULL is case insensitive! http://php.net/manual/en/langu...

And guess what : in some countries it might be customary to enter the family name in all caps (in France on written forms at least).
So, even if your parser or data entry doesn't uppercase the string it would be perfectly normal or even expected to have to deal with Jennifer NULL.

Okay, so I'll just install PHP on OpenBSD then.

And Facebook uses PHP which does support checking the difference between NULL and 0: http://php.net/manual/en/types.comparisons.php (look at the table of Strict comparisons with ===

Why does anyone care what is the "biggest" or "most important" open-source project ? That's like treating software in the same way as all that "Strictly Pop Idol Celebrity Chef Globes" TV garbage.

It's either *good* software, or it isn't, and that's the only criterion worth talking about.

Some of the best and most useful open-source software is also the smallest. Some of the most important and critical open-source software is also among the smallest and least 'recognised'. And some of the biggest open-source projects are also the biggest causes for concern.

Are we all hoping for prizes or something ?
Oh dear ... how childish.

What would be insanely easier is making a command that let you specify it directly rather than having 2 commands

I wonder how hard that would be to implement in terms of PHP output buffering.

There is no threading support whatsoever.

I'm pretty certain I have been using PHP threads for almost a decade now...?

Do you have an example of a particular function?

For example, ctype_upper() http://php.net/manual/en/funct...

There is no mb_ctype_upper. I wrote a workaround, for about 5 - 7 lines, but it would be nice to have this function for Cyrillic letters too.

Do you have an example of a particular function?

A lot of the old "core" functions do not support UTF-8. They support only single-byte encodings (pre-UTF8, ex: deprecated KOI encodings).

To give a silly example, mb_strtoupper() should be used instead of strtoupper(). http://php.net/manual/en/funct...

"The notion that you could fire a tread to do some heavy lifting while the rest of the application executes is, well, naive - the application only exits when all work is done."

That's not naivety, that's a deficiency in PHP, you're fobbing it off as a problem in understanding, when in reality it's simply that PHP is poorly designed. There's nothing inherently wrong with wanting to send something off for processing in the background so that the main execution thread can return a response to the user. The fact PHP can't do that is a problem with PHP, not naivety on behalf of someone wanting to do that because it's sometimes a legitimate thing to be able to do.

"Also, in some languages (e.g. Java) there is no guarantee that threads will execute on a separate processor, so its not obvious threading will translate directly into performance gains."

If you think thread usage is purely about performance then you also do not know enough to provide a reasonable response on this topic - responsiveness is kind of a big deal and a reason why threading is important in some applications. If you do not have enough experience of web applications to realistically understand why you would want threads then you cannot reasonably justify why it's okay that PHP doesn't well support threads.

"But hey, let me just point out that PHP actually has pthread support - http://php.net/manual/en/book...., so if anyone wants them, they can use them. "

No it doesn't. It has support for something with an identical name to POSIX threads that isn't POSIX threads. pthreads in PHP are PHP Threads, and they're not remotely the same thing as actual pthreads. PHP's implementation still has a number of deficiencies as it is constrained by PHP's deficient interpreter. It also has a number of pre-requisites that just aren't available on the vast majority of hosts. I believe it's still also even in beta anyway so hardly production ready.

So what you really mean here is that PHP has a 3rd party beta threading implementation that may or may not work on your host and doesn't offer the full range of functionality you would expect in a typical multi-threading library like the sort you get in say Java, or C# and that work out the box everywhere and have done for over a decade. All this ignores the absurdity of the broken argument being made here - PHP is fine because it doesn't need threads, but it's got a barely working threading implementation because it doesn't need it, what? The fact pthreads exists is evidence that there's a problem that needs solving. Before that it was solved in the most absurd ways by firing up a whole extra process with cURL, but you probably wont understand the performance implications of such a heavyweight action either.

"but what productive language doesn't require you to know more than 100 pages?"

We're not talking about 100 pages to be able to work with the language at all, we're talking at over a hundred pages of small gotchas once you've already been through learning the language itself - that is, we're talking about thousands of gotchas that just shouldn't exist in a sane language. For example, I shouldn't have to remember that PHP equality isn't transitive and the cases it behaves differently in for the simple that that in any sane fucking language equality should be transitive - it's a basic mathematical principle that all languages should follow if they've been even remotely thought through. It's that kind of shit that is the problem - tepples talked about coding standards to be able to even get PHP to a point where you don't end up creating bugs and vulnerabilities because of language pitfalls, but you can develop in Java, C#, C++, Python without needing any kind of coding standards as a fix to avoid bugs because of poor language design. Effectively to fix many of the problems documented that tepples writes off as being fixable with standards he's saying that you can make PHP work properly if you're willing to invest hundreds of extra hours