Slashdot Mirror

PHP has had its share of gotchas.

Just in the core, you've had the following changes:
4.1 to 4.2: register_globals default was changed from on to off.
4.x to 5.0: $HTTP_GET_VARS and $HTTP_POST_VARS are now disabled by default. Note that 4.0 didn't even have their replacements ($_GET and $_POST); they were introduced in 4.1.
5.x to 6.0 (coming soon): Safe mode is going to be removed entirely. magic_quotes_gpc is going to be removed entirely. Both of the settings mentioned in the previous lines are going to go (they were just disabled by default before).

That's completely ignoring things like the XSLT libraries being switched around... to my knowledge the 4.x library doesn't work on 5.x and vice versa.

PHP has had its share of gotchas.

Just in the core, you've had the following changes:
4.1 to 4.2: register_globals default was changed from on to off.
4.x to 5.0: $HTTP_GET_VARS and $HTTP_POST_VARS are now disabled by default. Note that 4.0 didn't even have their replacements ($_GET and $_POST); they were introduced in 4.1.
5.x to 6.0 (coming soon): Safe mode is going to be removed entirely. magic_quotes_gpc is going to be removed entirely. Both of the settings mentioned in the previous lines are going to go (they were just disabled by default before).

That's completely ignoring things like the XSLT libraries being switched around... to my knowledge the 4.x library doesn't work on 5.x and vice versa.

OWASP is invaluable for learning the WHY and HOW behind security.

But for an amateur, I think the first best thing he could do is apply the Suhosin patch for PHP: http://www.hardened-php.net/

This lets him worry about the why and how AFTER he's already closed many of the attack vectors a default PHP install leaves open. Especially if he's running below 5.2.x.

Furthermore, PHP has been more security focused since 5.01. You can learn a lot about security just by reading the release notes, even if you don't think you're learning about security!

For example, the filter_input() function. Instead of doing this:

$phone_number = $_POST['phone_number'];

do this:

$phone_number = filter_input(INPUT_POST, 'phone_number', FILTER_SANITIZE_STRING);

That simple change applied to all of your $_POST, $_GET (and/or $_REQUEST) look-ups will shut down most of your application-level attacks.

Any PHP developer should learn and ALWAYS use the new Filter features: http://us2.php.net/manual/en/ref.filter.php

Check EVERYTHING passed by the client. For PHP this would be PHP predefined variables, including things like REFERER, etc.

Also, take a look at installing Suhosin, if you have root access to your server. It's a PHP patch that adds more security on the binary level to combat certain common attack vectors like SQL injection (though that said, you should never simply rely on its protection without knowing how these attacks work and how to program defensively).

Speaking of which, PHP itself has a page on SQL injection and how to avoid it, which I recommend that you read and commit to memory if you don't already know about it. Especially for new developers in the PHP world, SQL injection is the number one security pitfall, and if you're uneducated about it, it's very easy to create insecure applications.

If you would like, I am a very experienced developer with about eight years of PHP experience. I can go through your code with you and tell you where you might be able to improve security. My rate is $30 / hour, but it probably won't take too long to give recommendations. If you're interested, please contact me at my first name at jamiearseneault.com.

PHP and MySQL aren't insecure per-se, it's just that people hack things together quickly with it that are insecure.

AFAIK PHP isn't vulnerable to buffer overflows directly. You have no control over pointers, so any stack overflows vulnerabilities have been in libraries, but exploited via PHP.

Standard MySQL functions in PHP don't support parameterized queries, but the MySQLi methods do, and MySQLi is installed on a lot of hosts these days. If it's not on a server then it's generally easy enough to add it.

The general hacks are the normal site exploits caused by people being taught to just use query strings and posted values as-is by beginner's books and then being hit with either SQL injection, command injection (if, for some reason, they do shell calls using variables), remote includes (passing a URL as a value that's include()d, which pulls in remote code if allow_url_fopen is enabled), or standard content injection to do things like put scripts on the page via a link when someone realises the values aren't validated.

The easiest way to prevent SQL injection is to use a library like MBD2 ( http://pear.php.net/package/MDB2 ) and use placeholders.

That way any data you use in SQL statements is automatically quoted.

Perl users have had this for ages with the DBI module, so SQL injection is much less likely in Perl than in PHP. Hackers like PHP ;)

Also AFAIK PHP has no convenient way of stripping Javascript from user input which also creates a risk.

X.

No.

You should be using prepared statements. And you should stop using the mysql_ functions. Use mysqli, or better yet, use PDO, or better better yet, use one of the dozens of great abstraction layers out there.

In any case, you've got a bad habit there. Don't feel too bad, though. By the looks of this thread, you're not alone. It's a trap: Beware of developing contorted reasoning for the purpose of avoiding changing your habits.

No.

You should be using prepared statements. And you should stop using the mysql_ functions. Use mysqli, or better yet, use PDO, or better better yet, use one of the dozens of great abstraction layers out there.

In any case, you've got a bad habit there. Don't feel too bad, though. By the looks of this thread, you're not alone. It's a trap: Beware of developing contorted reasoning for the purpose of avoiding changing your habits.

What language is !== considered an inequality operator? C, C++, C#, Java, Python, PHP, Ruby (and the list goes on) all use != as the inequality operator.

Strict inequality operator (I believe there are others too).

Outdated. Server roles on wikitech is probably more up-to-date: I count over 70 Squids there at least, and 35 DB servers (although not all are listed as used). That's probably not terrible accurate either, though. Ganglia claims 274 hosts up right now, but clearly lists too few Apaches to be correct. Last I heard, anyway, the Apache count was around 300.

At any rate, Wikipedia is certainly an efficient operation, yes. PHP is an awful language, but its efficiency is not much worse than Python or Perl or whatever. The major costs IMO are in development time:

1. More time reimplementing basic functionality, because libraries aren't available reliably. A ton of critical library functions (e.g., the entire mbstring module, which is necessary for dealing with Unicode) aren't available on all installations -- installing a new module typically requires root access. Thus for code to work reliably, you need to write workalikes for all the major functions. Also, where library functions are reliably available, they're often fairly braindead and you have to write sane workalikes anyway, or wrappers that make their functionality more reasonable. I was just spending time working on an implementation of parse_url() that actually works for URL schemes like mailto: and news: that are absolutely conformant to the URL RFC but don't use "://" as a separator, so PHP evidently doesn't care about them.
2. Time working around site-specific config settings that can't be changed at runtime. For instance, if magic_quotes_gpc is enabled, you have to write code to strip the quotes yourself, because PHP doesn't provide this. Any app that wants to work across all PHP configurations must implement that from scratch. There are even more horrible settings: mbstring.func_overload is one that's so horrifyingly broken that a sane app has no option but to give up and refuse to run until it's disabled. (It silently replaces all functions like strlen() with UTF-8 versions -- meaning everything that you thought was measuring bytes suddenly measures UTF-8 characters.) MediaWiki actually does this (grep for "func_overload" or "magic_quotes_runtime").
3. Time working around bugs caused by PHP language misfeatures. Maybe MediaWiki devs are all just bad at PHP, but there are regular commits to fix bugs caused by the same few language features. For instance, "!$str" to check if a string is empty will fail exactly in the rare (and thus hard-to-track-down) special case that $str is equal to "0". In the same vein, but more uniquely to PHP as far as I know, "random string" will evaluate as equal to zero if compared to an integer, and this periodically causes bugs too. (I would expect them to be unequal if the string can't be cast to an integer, at least, and preferably never equal at all.) These can be solved with discipline, at least, like always using ===.

Outdated. Server roles on wikitech is probably more up-to-date: I count over 70 Squids there at least, and 35 DB servers (although not all are listed as used). That's probably not terrible accurate either, though. Ganglia claims 274 hosts up right now, but clearly lists too few Apaches to be correct. Last I heard, anyway, the Apache count was around 300.

At any rate, Wikipedia is certainly an efficient operation, yes. PHP is an awful language, but its efficiency is not much worse than Python or Perl or whatever. The major costs IMO are in development time:

1. More time reimplementing basic functionality, because libraries aren't available reliably. A ton of critical library functions (e.g., the entire mbstring module, which is necessary for dealing with Unicode) aren't available on all installations -- installing a new module typically requires root access. Thus for code to work reliably, you need to write workalikes for all the major functions. Also, where library functions are reliably available, they're often fairly braindead and you have to write sane workalikes anyway, or wrappers that make their functionality more reasonable. I was just spending time working on an implementation of parse_url() that actually works for URL schemes like mailto: and news: that are absolutely conformant to the URL RFC but don't use "://" as a separator, so PHP evidently doesn't care about them.
2. Time working around site-specific config settings that can't be changed at runtime. For instance, if magic_quotes_gpc is enabled, you have to write code to strip the quotes yourself, because PHP doesn't provide this. Any app that wants to work across all PHP configurations must implement that from scratch. There are even more horrible settings: mbstring.func_overload is one that's so horrifyingly broken that a sane app has no option but to give up and refuse to run until it's disabled. (It silently replaces all functions like strlen() with UTF-8 versions -- meaning everything that you thought was measuring bytes suddenly measures UTF-8 characters.) MediaWiki actually does this (grep for "func_overload" or "magic_quotes_runtime").
3. Time working around bugs caused by PHP language misfeatures. Maybe MediaWiki devs are all just bad at PHP, but there are regular commits to fix bugs caused by the same few language features. For instance, "!$str" to check if a string is empty will fail exactly in the rare (and thus hard-to-track-down) special case that $str is equal to "0". In the same vein, but more uniquely to PHP as far as I know, "random string" will evaluate as equal to zero if compared to an integer, and this periodically causes bugs too. (I would expect them to be unequal if the string can't be cast to an integer, at least, and preferably never equal at all.) These can be solved with discipline, at least, like always using ===.

Outdated. Server roles on wikitech is probably more up-to-date: I count over 70 Squids there at least, and 35 DB servers (although not all are listed as used). That's probably not terrible accurate either, though. Ganglia claims 274 hosts up right now, but clearly lists too few Apaches to be correct. Last I heard, anyway, the Apache count was around 300.

At any rate, Wikipedia is certainly an efficient operation, yes. PHP is an awful language, but its efficiency is not much worse than Python or Perl or whatever. The major costs IMO are in development time:

1. More time reimplementing basic functionality, because libraries aren't available reliably. A ton of critical library functions (e.g., the entire mbstring module, which is necessary for dealing with Unicode) aren't available on all installations -- installing a new module typically requires root access. Thus for code to work reliably, you need to write workalikes for all the major functions. Also, where library functions are reliably available, they're often fairly braindead and you have to write sane workalikes anyway, or wrappers that make their functionality more reasonable. I was just spending time working on an implementation of parse_url() that actually works for URL schemes like mailto: and news: that are absolutely conformant to the URL RFC but don't use "://" as a separator, so PHP evidently doesn't care about them.
2. Time working around site-specific config settings that can't be changed at runtime. For instance, if magic_quotes_gpc is enabled, you have to write code to strip the quotes yourself, because PHP doesn't provide this. Any app that wants to work across all PHP configurations must implement that from scratch. There are even more horrible settings: mbstring.func_overload is one that's so horrifyingly broken that a sane app has no option but to give up and refuse to run until it's disabled. (It silently replaces all functions like strlen() with UTF-8 versions -- meaning everything that you thought was measuring bytes suddenly measures UTF-8 characters.) MediaWiki actually does this (grep for "func_overload" or "magic_quotes_runtime").
3. Time working around bugs caused by PHP language misfeatures. Maybe MediaWiki devs are all just bad at PHP, but there are regular commits to fix bugs caused by the same few language features. For instance, "!$str" to check if a string is empty will fail exactly in the rare (and thus hard-to-track-down) special case that $str is equal to "0". In the same vein, but more uniquely to PHP as far as I know, "random string" will evaluate as equal to zero if compared to an integer, and this periodically causes bugs too. (I would expect them to be unequal if the string can't be cast to an integer, at least, and preferably never equal at all.) These can be solved with discipline, at least, like always using ===.

Well, the same is true also for Perl, PHP, Python and even Lua, so that's nothing radically new.

Exactly what the other poster said--header injection.

The form asked for a "From" name and email address, and had a textarea for the email body.

The form then used the PHP's mail function (http://us3.php.net/manual/en/function.mail.php) including the additional_headers field to add the From name and email address to the mail (so that the recipient could just click reply to reply to the sender). The subject line and "to" parameters were set by the program to a limited number of possibilities. I'm assuming that's how the injection was done, so that by crafting a message correctly, the person could send an email to not just to the person in the "to" field, but to anybody.

Well at my college we are all Linux, they start you off with C++, but IMO I think they should start off with Python to ease in the freshmen. I would suggest Django/Python for web programming (I am in the process of learning), also PHP (which I love and currently do all my side projects in) as for non web programming I would go with C/C++, and dare I say Java.

You can find Python book online, and Django book as well.

For a good IDE I really like Geany, it works well with a Linux system, and it's light weight. It looks for installed compilers so you don't have install anything on top it as long as you have all the stuff you needs like GCC, OpenJDK, etc.

Although they are planning to introduce some new ones to keep things real.

Cookies don't necessarily mean that they're tracking information. Cookies are an essential part of sessions (at least in PHP).

Not true. If the user doesn't have cookies enabled, the session data is appended to the url.

What doesn't help is that the standard PHP distribution has no support for prepared statements.

yes it does.

You have to compile with mysqli and most distributions don't go to that trouble.

mysqli is an extension, and installing that module is just a pecl/apt-get/yum/pkg_add away. PHP has gobs of functionality implemented as modules, which you can add/remove as needed.

And if you go out of your way to use mysqli, you can't use half the documentation on the web and certainly not the documentation on php.net.

why not? the documentation seems on par with the rest.

It does reinforce my belief that PHP is for script kiddies and unsuitable for serious web development.

script kiddies are unskilled people that run other peoples scripts/programs for nefarious purposes on the interwebs. at least get your insults right, your UID is low enough.

Businesses still relying on it will find out the hard way in the coming years, because teh php community will keep falling further behind.

I agree with the low barrier of entry and questionable quality of most programmers, but if you know what you're doing PHP can get you far. and that also goes for all popular languages.

yes is true that i like to have strong opinions and yes i could be
wrong in most of them
but when all the comunity screems at the namespace issue i think
core developers should be more diplomatic and offer the good solution not
close the eyes and wash the hands and go forward

an semisolution would be an php.ini variable
like
NAMSPACE_SEPARATOR="::"
so if you have an issue with your classes can be reset to "\" or
whatever with ini_set

i think it's easy to be done if i look at the patch that created the
backslash separator issue
http://pear.php.net/~greg/backslash.sep.patch.txt

But there's something else that PHP miss: a "static" keyword.

http://us2.php.net/manual/en/language.oop5.static.php

But there's something else that PHP miss: a "static" keyword.

Not so.

#include <iostream>

using namespace std;
namespace foo {
void bar(void) { cout << "func" << endl; }
};

class foo {
public:
static void bar(void) { cout << "method" << endl; }
};

int main(void)
{
foo::bar();
return 0;
}

Trying to compile the example with g++ gives a strange result. While the class-definition successfully hides the namespace, the two method definitions seem to clash at the linking stage.

/tmp/ccXa637g.s: Assembler messages:
/tmp/ccXa637g.s:181: Error: symbol `_ZN3foo3barEv' is already defined

Myself I would try a lot of other things before using a backslash as separator though. The syntax is out of the ordinary (compared to other languages) and it's likely that it'll cause problems elsewhere.

For additionnal fun, read this: http://wiki.php.net/rfc/namespaceseparator

Looks like they considered stuff like :> and :) as separators for namespace. Seriously.
Also, they don't give any malus for tybe-ability to \ while on most european keyboards it's a lot harder than any other suggested separator. Way to go !

Looking at the IRC discussion it seems that they didn't have much of a choice.

The rfc claims that typing "**" is easier than typing "%%" or "^^".

PHP: Hipertext Preprocesor.

why? so you can save .025 seconds by not reloading an index or menu?

there's no good reason to use frames or even iframes in a modern site. it's bad for search engine indexing, and it's bad for usability. that is why major API documentation sites like those for the YUI Library, MySQL, PHP, and even MSDN do not use frames in their layout.

even if there were a need to keep persistent layout elements, you can use AJAX to simulate all of the desirable behaviors of frames/iframes without the drawbacks.

why? so you can save .025 seconds by not reloading an index or menu?

there's no good reason to use frames or even iframes in a modern site. it's bad for search engine indexing, and it's bad for usability. that is why major API documentation sites like those for the YUI Library, MySQL, PHP, and even MSDN do not use frames in their layout.

even if there were a need to keep persistent layout elements, you can use AJAX to simulate all of the desirable behaviors of frames/iframes without the drawbacks.

isn't PHP supposed to include closures soon?

i don't know much about closures but that's just what i've read while researching closures in PHP. in what kind of situation would you specifically need to use closures? couldn't you still create bound variables through nested or recursive functions? or do closures serve a more explicit purpose that cannot be achieved any other way?

also, what language would you recommend for web development that are more robust than PHP?

The problem with teaching PHP to beginners is that you also need to teach them HTML.

No, actually, you don't!

For your enlightenment:

http://www.sitepoint.com/article/php-command-line-1/
http://gtk.php.net/
http://www.php-qt.org/
http://php-tk.sourceforge.net/documentation.html
http://www.bluem.net/downloads/pashua_en/
http://sourceforge.net/projects/phpopengl/

``It is unfortunate that the mono is so closely associated with Windows, if the mono team had created/implemented a
completely new set of cross-platform libraries (that bore no relation to Microsoft's framework) it would be more accepted.''

But then they would just have done what various others have already done, wouldn't they?

For Perl I always have a copy of Beginning Perl on my hard drive. But it's also always the first hit on Google for beginning perl if you have to change the computer. I know, it's a PDF and it therefore has no cool AJAX Web 2.0ish effects but the function reference is great and whenever I forget how to create an anonymous hash reference and whatnot (which easily happens to me when not programming Perl for a while): it's there.

For PHP I always use php.net. I never searched for something PHP related I couldn't find there.

I use PHP every day. I love PHP. It is an awesome, flexible, powerful, responsive rapid application development language for any kind of text processing and "cloud services" need. It's typical for me to write 10-20 lines of simple, elegant PHP code that performs wonders matched only by hundreds of lines of C. I'll put it simply: I've bet my farm on PHP, and it's paid off wonderfully. It's stable, fast, and extremely dense when measured in functionality per line of code.

But my one true beef with PHP - one of two beefs in all - is its inconsistent API.

For example:

Here's one that drives me nuts to no end: in_array($needle, $haystack); vs strstr($haystack, $needle);

Here's another that makes x-platform DB stuff a serious pain: mysql_query($query, $db_connection); compared to pg_query($db_connection, $query);

I mean, WTF? How could I possibly remember the difference between these two almost identical functions with EXACT OPPOSITE PARAMETER ORDER!?!?! So php.net gets hit by me. Daily. Constantly. Zend pays the price for not thinking through the conventions of their API with my daily hits on their website.

I would *LOVE* a fork of PHP where the ordering is consistent. To be fair, the fork would have to be retro-compatible with the existing PHP API so that current PHP scripts don't break. This may be more painful than it's worth; I'd suggest prepending all functions in the alternate API with some special character (eg: "_" or "^" as in _mysql_query($conn, $query); )

My other beef? Lack of thread support. It may be due to the apache process limits of mod_php, but the fact that I can't run several threads inside a single memory space sometimes just drives me NUTS. So when lots of work needs to be done by lots of processors in a very short period of time, I have to fork() like crazy with a PHP script run from a shell call with shmop_* or temporary named pipes all over the place. It's fugly to say the least. Thankfully, the number of problems that won't fit into a single process (sans threading) are small, so the hack level is kept to a minimum - for now.

As processes get bigger, and processors develop ever more cores, this limitation will become increasingly a problem. Already, it's normal for a new, mid-range server to have 16 cores, each running at > 2 Ghz, which means that any single PHP script can only access 1/16 of the total available processing power. With current trends, in another couple years that will jump to 64 cores, and at that level, thread support becomes almost a requirement, even for highly parallel, concurrent activity.

Seriously - who wants to be limited to using only 1/64 of the available processing power? Not me. I hope that PHP 6 handles this.

Oh... go PHP.net!

I use PHP every day. I love PHP. It is an awesome, flexible, powerful, responsive rapid application development language for any kind of text processing and "cloud services" need. It's typical for me to write 10-20 lines of simple, elegant PHP code that performs wonders matched only by hundreds of lines of C. I'll put it simply: I've bet my farm on PHP, and it's paid off wonderfully. It's stable, fast, and extremely dense when measured in functionality per line of code.

But my one true beef with PHP - one of two beefs in all - is its inconsistent API.

For example:

Here's one that drives me nuts to no end: in_array($needle, $haystack); vs strstr($haystack, $needle);

Here's another that makes x-platform DB stuff a serious pain: mysql_query($query, $db_connection); compared to pg_query($db_connection, $query);

I mean, WTF? How could I possibly remember the difference between these two almost identical functions with EXACT OPPOSITE PARAMETER ORDER!?!?! So php.net gets hit by me. Daily. Constantly. Zend pays the price for not thinking through the conventions of their API with my daily hits on their website.

I would *LOVE* a fork of PHP where the ordering is consistent. To be fair, the fork would have to be retro-compatible with the existing PHP API so that current PHP scripts don't break. This may be more painful than it's worth; I'd suggest prepending all functions in the alternate API with some special character (eg: "_" or "^" as in _mysql_query($conn, $query); )

My other beef? Lack of thread support. It may be due to the apache process limits of mod_php, but the fact that I can't run several threads inside a single memory space sometimes just drives me NUTS. So when lots of work needs to be done by lots of processors in a very short period of time, I have to fork() like crazy with a PHP script run from a shell call with shmop_* or temporary named pipes all over the place. It's fugly to say the least. Thankfully, the number of problems that won't fit into a single process (sans threading) are small, so the hack level is kept to a minimum - for now.

As processes get bigger, and processors develop ever more cores, this limitation will become increasingly a problem. Already, it's normal for a new, mid-range server to have 16 cores, each running at > 2 Ghz, which means that any single PHP script can only access 1/16 of the total available processing power. With current trends, in another couple years that will jump to 64 cores, and at that level, thread support becomes almost a requirement, even for highly parallel, concurrent activity.

Seriously - who wants to be limited to using only 1/64 of the available processing power? Not me. I hope that PHP 6 handles this.

Oh... go PHP.net!

I use PHP every day. I love PHP. It is an awesome, flexible, powerful, responsive rapid application development language for any kind of text processing and "cloud services" need. It's typical for me to write 10-20 lines of simple, elegant PHP code that performs wonders matched only by hundreds of lines of C. I'll put it simply: I've bet my farm on PHP, and it's paid off wonderfully. It's stable, fast, and extremely dense when measured in functionality per line of code.

But my one true beef with PHP - one of two beefs in all - is its inconsistent API.

For example:

Here's one that drives me nuts to no end: in_array($needle, $haystack); vs strstr($haystack, $needle);

Here's another that makes x-platform DB stuff a serious pain: mysql_query($query, $db_connection); compared to pg_query($db_connection, $query);

I mean, WTF? How could I possibly remember the difference between these two almost identical functions with EXACT OPPOSITE PARAMETER ORDER!?!?! So php.net gets hit by me. Daily. Constantly. Zend pays the price for not thinking through the conventions of their API with my daily hits on their website.

I would *LOVE* a fork of PHP where the ordering is consistent. To be fair, the fork would have to be retro-compatible with the existing PHP API so that current PHP scripts don't break. This may be more painful than it's worth; I'd suggest prepending all functions in the alternate API with some special character (eg: "_" or "^" as in _mysql_query($conn, $query); )

My other beef? Lack of thread support. It may be due to the apache process limits of mod_php, but the fact that I can't run several threads inside a single memory space sometimes just drives me NUTS. So when lots of work needs to be done by lots of processors in a very short period of time, I have to fork() like crazy with a PHP script run from a shell call with shmop_* or temporary named pipes all over the place. It's fugly to say the least. Thankfully, the number of problems that won't fit into a single process (sans threading) are small, so the hack level is kept to a minimum - for now.

As processes get bigger, and processors develop ever more cores, this limitation will become increasingly a problem. Already, it's normal for a new, mid-range server to have 16 cores, each running at > 2 Ghz, which means that any single PHP script can only access 1/16 of the total available processing power. With current trends, in another couple years that will jump to 64 cores, and at that level, thread support becomes almost a requirement, even for highly parallel, concurrent activity.

Seriously - who wants to be limited to using only 1/64 of the available processing power? Not me. I hope that PHP 6 handles this.

Oh... go PHP.net!

I use PHP every day. I love PHP. It is an awesome, flexible, powerful, responsive rapid application development language for any kind of text processing and "cloud services" need. It's typical for me to write 10-20 lines of simple, elegant PHP code that performs wonders matched only by hundreds of lines of C. I'll put it simply: I've bet my farm on PHP, and it's paid off wonderfully. It's stable, fast, and extremely dense when measured in functionality per line of code.

But my one true beef with PHP - one of two beefs in all - is its inconsistent API.

For example:

Here's one that drives me nuts to no end: in_array($needle, $haystack); vs strstr($haystack, $needle);

Here's another that makes x-platform DB stuff a serious pain: mysql_query($query, $db_connection); compared to pg_query($db_connection, $query);

I mean, WTF? How could I possibly remember the difference between these two almost identical functions with EXACT OPPOSITE PARAMETER ORDER!?!?! So php.net gets hit by me. Daily. Constantly. Zend pays the price for not thinking through the conventions of their API with my daily hits on their website.

I would *LOVE* a fork of PHP where the ordering is consistent. To be fair, the fork would have to be retro-compatible with the existing PHP API so that current PHP scripts don't break. This may be more painful than it's worth; I'd suggest prepending all functions in the alternate API with some special character (eg: "_" or "^" as in _mysql_query($conn, $query); )

My other beef? Lack of thread support. It may be due to the apache process limits of mod_php, but the fact that I can't run several threads inside a single memory space sometimes just drives me NUTS. So when lots of work needs to be done by lots of processors in a very short period of time, I have to fork() like crazy with a PHP script run from a shell call with shmop_* or temporary named pipes all over the place. It's fugly to say the least. Thankfully, the number of problems that won't fit into a single process (sans threading) are small, so the hack level is kept to a minimum - for now.

As processes get bigger, and processors develop ever more cores, this limitation will become increasingly a problem. Already, it's normal for a new, mid-range server to have 16 cores, each running at > 2 Ghz, which means that any single PHP script can only access 1/16 of the total available processing power. With current trends, in another couple years that will jump to 64 cores, and at that level, thread support becomes almost a requirement, even for highly parallel, concurrent activity.

Seriously - who wants to be limited to using only 1/64 of the available processing power? Not me. I hope that PHP 6 handles this.

Oh... go PHP.net!

C#/.NET - http://msdn.microsoft.com/
Haskell - http://haskell.org/
Nemerle - http://nemerle.org/
OCaml - http://caml.inria.fr/
PHP - http://php.net/
Python - http://python.org/
Ruby - http://ruby-doc.org/ (API docs), http://ruby-lang.org/ (for more links and info)
SML - http://smlnj.org/ (the most popular implementation), http://standardml.org/Basis/ (standard library)

(X)HTML/CSS/DOM/XSL/etc. - http://w3.org/

Hm. Now that I've written it down, I see most of these are obvious, but then it makes sense, that the "official" sites tend to be the best reference.

Java:
http://java.sun.com/javase/6/docs/api/

I do a little happy dance in my head every time this site helps me out. it's a bit intimidating until you use it, then it becomes the best java reference you could ask for.

Ruby:

use fxri. in windows, it's not just a live command-line style interpreter, it has a dictionary of relevant terms to search through to boot. it's like having a terminal inside of a reference book, and you shouldn't pass up the opportunity to try it out.

php:
http://www.php.net/docs.php

this one I use every time I use php. Not only does it tell you what everything does, but it tells you what's bugged, and how, and that way you can work around what would otherwise be a nasty problem.

I use these constantly at my job (fxri is the only calculator I know of that can calculate the factorial of 6022, so I use it for all my calculations!) and I hope you find them just as useful as I do.

http://www.php.net/

This is a very good point. Except that phpMyAdmin makes it really easy to set up a new database with a single user who has all rights, and the same name as the DB.

So what I tend to do (and I do admit that I am a lazy SOB), is just create a new DB and user for every app.

However, your idea is much better, and it would be nice if phpMyAdmin had such a feature... (Not that I'm about to code it in, on account of my being busy with other things, and never having even looked at the phpMyAdmin code beyond what is needed to install it.)

However, an even better thing to do (then just create a read-only user), is to escape shit before you query the DB... PHP and MySQL have this nifty function mysql_real_escape_string which will do that for you. It is better then using the general escape functions in PHP, for reasons that I read just recently. Basically, it takes into account the character encoding for the DB... http://shiflett.org/blog/2006/jan/addslashes-versus-mysql-real-escape-string

I did this with our own web-based product and found out that yes, indeed, we are insecure. It took a few minutes of poking around to find out how to secure our site.

So, for everybody else: if you are using PHP, you need to pay attention to Set_Cookie_Params() . Here's the 1-liner call that we make in order to solve this problem for us, before any calls to session_register():

Session_Set_Cookie_Params(720, '/', $_SERVER['SERVER_NAME'], true);

Parameters:

1) 720: Our sessions timeout after 2 hours.

2) '/': the cookie applies to all paths within our site.

3) $_SERVER['SERVER_NAME']: applies only to the specific domain name originally called. (we use subdomains, so this is important)

4) true: (the most important one), this means that the cookies can only be used over SSL.

I see a lot of people saying that they're surprised anyone's still using PHP 4, when PHP 5 has been out for so long. Well, I can guarantee you there's a lot of legacy PHP 4 codebases out there; converting to 5 is not always as easy as going over what's in the migration page on php.net. Just to give you an idea of the magnitude, we have tends of thousands of code files spread across numerous systems; our live web pool is around 100 machines, and we cannot take the website down in order to update it. (I can't tell you why.) So updates have to be made live. We don't have a proper staging environment, either, but we have come up with a number of (horrible) mechanisms for dealing with this situation.

In our particular (unfortunate) case, we had about half a dozen custom PHP extensions that were all written by our former CTO, who left the company about a year and a half ago. He wasn't really big into documentation, and our technical management was very poor; we had a guy go through our 65,000-file codebase and make all the little tweaks necessary for a vanilla 4-to-5 migration, but it took us six months of wrangling with all these extensions to get them to work well under 5.1 (we're still having trouble with 5.2).

Plus, it's not just a matter of dealing with the technology; like a lot of companies, management here doesn't like to put resources into things that don't have visible benefits -- and cleaning up the codebase/rebuilding the dev environment just isn't something they see a lot of value in. (We've finally convinced them it's important and needs to be done; we're operating without source control for about 99% of our code. YES, I KNOW.) We didn't even seriously start pushing to get things up to PHP 5 until January, and it took until July to actually make it happen.

The point is, mismanagement and bad development environment/codebase design early on (several years ago) have meant that we're upgrading to PHP 5 years later than we should have. It's not that we didn't know how to do it once we decided to.

http://docs.php.net/manual/en/migration5.php

Actually, PHP uses both != / !== and == / === as comparison operators.

== / != checks that the values are "equal" (same value, but not necessarily the same type; ie. 1 == "1" is true)
=== / !== checks that the values are "identical" (same value and data type; ie. 1 === "1" is false)

See http://php.net/operators.comparison

1. believe me, PHP by itself runs on more webservers and sites than all the .NET languages put together. Probably more than .NET languages and ASP/classic too!

Netcraft stats for PHP - over 20 million sites a year ago. According to the same Netcraft survey, IIS itself only runs 20 million sites, so unless *every* IIS site ran ASP (note: these stats are from Aug 2007, so they'd all be classic ASP) PHP would *still* be running on more active sites.
There's more stats available for the current month.

2. Silverlight is a client-side technology. IIS/apache doesn't come into it. A silverlight discussion would be MS supporting it on Firefox on Linux.

3. MS is the market leader only in certain segments of the IT marketplace. For webserving, Apache has been dominant for, well, since forever. MS is catchign up as they provide 'incentives' for some providers - eg Myspace, GoDaddy etc, which you'll see on the netcraft stats.

4. The problem is that you'd never get .NET on Linux, which is Apache's native platform. Though Apache runs on Windows I guess MS may be trying to get developers to program in .NET using Apache and they be as locked in to Windows server platform as if they had stuck with IIS. I think this is the goal for this sponsorship.

To answer your question - should MS drop Silverlight because you can do the same in Javascript and Flash (Flex), then the answer is no. Should *you* drop Silverlight because you can do the same in a free technology on any platform you choose, then the pragmatic answer is probably yes. Simply, if you stick with C# then you're stuck with Windows. If you choose PHP then you can choose any platform you like.

If you're a PHP programmer, you're irresponsible if you're not already aware of its flaws, because you have not educated yourself by reading any of the following well publicized articles. Once you understand the flaws of PHP, you can't honestly make the statement that it's a well designed language suitable for teaching programming to kids.

First there is this classic article, Edwin Martin's "What I don't Like about PHP", which goes into detail about the following fundamental flaws:

1. Bad recursion
2. Many PHP-modules are not thread safe
3. PHP is crippled for commercial reasons
4. No namespaces
5. Non-standard date format characters
6. Confusing licenses
7. Inconsequent function naming convention
8. Magic quotes hell
9. Framework seldom used
10. No Unicode
11. Slow

Then there is the mind-set of the PHP language designers and community, which is deeply flawed. Ian Bicking's "PHP Ghetto" article sums up the problem with PHP's design and community pretty well:

I think the Broken Windows theory applies here. PHP is such a load of crap, right down to the standard library, that it creates a culture where it's acceptable to write horrible code. The bugs and security holes are so common, it doesn't seem so important to keep everything in order and audited. Fixes get applied wholesale, with monstrosities like magic quotes. It's like a shoot-first-ask-questions-later policing policy -- sure some apps get messed up, but maybe you catch a few attacks in the process. It's what happened when the language designers gave up. Maybe with PHP 5 they are trying to clean up the neighborhood, but that doesn't change the fact when you program in PHP you are programming in a dump.

Jonathan Ellis' "Why PHP sucks" article makes a lot of good points and links to many other sites with more information to back up the claim that PHP sucks.

He perfectly summarizes the yapping of the PHP apologists when he says: Basically these all boil down to, "I don't have enough experience to recognize PHP's flaws because I haven't used anything better."

He summarizes:

In short, PHP sucks because, PHP's authors are prone to confuse "pragmatism" (a fine design goal, if done well) with "adding random features without considering how they impact the language as a whole." Thus, its authors have found it necessary to correct obvious flaws in both minor and major releases, with the result that the recent PHP5 breaks with the past to an unprecedented degree while still leaving many fundamental flaws un-addressed. I don't know if this is because they didn't recognize those flaws, or more likely, because they were willing to impose "requires a lot of pain to upgrade" but not "requires a complete re-write."

There is also a lot of great stuff about why PHP is so bad on http://www.ranting-wolf.info/category/technology/programming/php/ including a concise description of why the "Smarty" templating system is such a horribly ill conceive and terribly implemented idea.

And if you're still not convinced the design of PHP is deeply flawed, because language design is HARD and should only be attempted on purpose by experienced people, here's what the Father of PHP Rasmus Lerdorf himself said in an ITConversations interview, quoted in "Why PHP sucks, Part III":

"I don't know how to stop it, there was never any intend to writ

Mozilla Firefox licensing: MPL/GPL/LGPL/Mozilla EULA (for binary redistribution)

PHP has stopped GPL licensing since PHPv4 and offers this response in their FAQ:

http://www.php.net/license/

Q. You suck! I'm going to take the last version of PHP 3 that was distributed under the GPL and fork! How would you like that?

A. With fries.

Well, there are a lot of great GPL-licensed projects written in PHP, so I won't worry about the choices made by the PHP developers for now, but I'll be paying more attention to the direction of PHP in the future because I already didn't like the way the Zend Optimizer is licensed.

Mozilla Firefox is still one of the flag-ship GPL-licensed projects. If that ever changed, I'd find another browser. To me, one of the important parts of the GPL is the preamble, which gives voice to my thoughts and feelings on the subject of software freedom.

Another license may be GPL-compatible or acknowledged as meeting the criteria for the definition of Free Software, but I'm pretty enthusiastic about the socially-engaged vision of the GNU project. I tend to be drawn to projects which, by their choice of license, extend the reach of the FSF/GNU message.

My current work environment seems to be quite similar to yours. Although I do not consider myself a master, I'm definitely a jack of all trades. Fax machines, copiers, computer networks (Linux, Windows), Intranet sites design, etc.

How do I keep current? Just reading the manuals.

• Web design? w3.org / www.php.net
• Networks? Microsoft Support
• Copiers, faxes and other hardware? manufacturers' sites

This is honestly where i've learned all what i know now.

"One interesting thing I've found talking to average Joe (who doesn't have any personal agenda to fulfil as to whether they use IE or Firefox) is that they find all this Firefox publicity as vain"

I've never come across an average Joe that has even heard of a 'release candidate', never mind knowing what one is. I don't believe they are aimed at the average Joe, unless you know different. People would be off directing them to the current stable release. I mean without 'release candidates', Mozilla would they get less user feedback and retard the development of Firefox ..

"Release candidates are development packages released to check if any critical problems have slipped into the code during the previous development period"