Slashdot Mirror

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

The only book you need. Sheesh, read the fucking manual people.

Disclaimer: The opinions expressed in the following comment are of my own. Please do not flame or complain because I do not share the same opinion as you.

PHP is not that bad of a language. Yes, it has it's issues and has brought on it's own stereotype because of it's ease of use. But really, when it comes to getting things done and done quick.. PHP excels very well.

I use PHP on a daily basis. Not just for work (I am a web developer by profession), but for quick dirty hacks (especially when bash is not available) it is great too. I've written entire daemons that watch and entire directory tree (1000+ files) and will alert me in some way of something happens, etc. I've written a IRC-style chat system way back in the day, and so on.

PHP has GTK, and apparently QT (server appears to be down ATM) bindings now. It has a lot of really useful low-level bindings, such as FAM. Along with Sockets and friends PHP is very powerful. Especially if you can get out of the mentality that "PHP was designed for websites." :-)

PHP really has evolved... I am very greatly anticipating the upcoming PHP 6. NAMESPACES! I can't wait.

I've used and worked with Ruby, Python, TCL, etc. etc. PHP just sits right with me.

Disclaimer: The opinions expressed in the following comment are of my own. Please do not flame or complain because I do not share the same opinion as you.

PHP is not that bad of a language. Yes, it has it's issues and has brought on it's own stereotype because of it's ease of use. But really, when it comes to getting things done and done quick.. PHP excels very well.

I use PHP on a daily basis. Not just for work (I am a web developer by profession), but for quick dirty hacks (especially when bash is not available) it is great too. I've written entire daemons that watch and entire directory tree (1000+ files) and will alert me in some way of something happens, etc. I've written a IRC-style chat system way back in the day, and so on.

PHP has GTK, and apparently QT (server appears to be down ATM) bindings now. It has a lot of really useful low-level bindings, such as FAM. Along with Sockets and friends PHP is very powerful. Especially if you can get out of the mentality that "PHP was designed for websites." :-)

PHP really has evolved... I am very greatly anticipating the upcoming PHP 6. NAMESPACES! I can't wait.

I've used and worked with Ruby, Python, TCL, etc. etc. PHP just sits right with me.

MySQL supports [named] placeholders just fine. It is PHP that does not. PHP is the suck for databases unless you use PDO. See examples 1737 for named placeholders and 1738 and 1739 for prepared statements.

I recommend prepared statements with positional placeholders (the '?' style) as the exact same sytax is used with Java, PHP, and Perl.

Applications requiring one database or another should be ancient history. However, whenever you look up a how to access MySQL from PHP, you'll find stuff that recommends using all the mysql_* functions. This is the quick way to creating an app that absolutely depends on MySQL. Really people should be using PDO, instead of mysql_ or pgsql_. Of course the real solution is to use a database abstraction layer, but I've never found a good way to create an n-tier web appliction in PHP.

http://en.wikipedia.org/wiki/Prior_art

Actually, those are page titles, not search terms... you can't just go to "http:/en/wikipedia.org/wiki/search terms", you have to go to "http://en.wikipedia.org/wiki/Special:Search?search=search+terms&go=Go".

There probably ARE examples of prior art, but Wikipedia isn't one of them.

Agreed. The one that springs to mind is php.net.

Find a "web search engine" that does this and you've come closer to finding prior art.

Um, like php.net/isset?

this is not a subset - mod_rewrite (or however they wish to implement it) is being applied to something very specific that no one else did/thought-of before - web search engines.

OK, what do you use as a definition of 'subset'? In my world, when something general (casting path info as an argument to a script) is applied to something specific (casting path_info as an argument to a search engine script) we call that applying the tech to a subset of it's possible uses.

As someone pointed out above, I was wrong when I said it breaks the HTML spec. The use of '/' following the script name is acceptable usage for single argument transfer in CGI, the '?' is used to denote multiple arguments which are to be automagically parsed. So it's even worse, they patented part of an existing standard.

Thanks - you've just shown another reason why this is non-obvious - it does something with the technology that was not intended for, not common practice, etc...

OK, I'm a geek, I've used 8oz propane tanks and an M80 to remove tree stumps. It meets all your criteria, but it's still obvious.

If you believe it to be a "stupid patent" then you may wish to re-read it again, I see the use of it and some technological advancement (sure perhaps minor but almost all of civilization has been from minor inventions along the way).

I have read it, it's still stupid - yes it has uses, but it's certainly not a technological advancement. It's something that's been around since mod_rewrite as a codified structure & available earlier than that as customized 404 pages. Slapping 'for search engines' on it doesn't make it innovative. It makes it a waste of everyones time.

For the record we now have:

1. mod_rewrite
2. perlhandler
3. customized 404 error pages
4. .htaccess
5. javaServelets
6. webserver hacks
7. <insert other here>

If I'm not mistaken php.net basically does the same thing for searching documentation:
http://www.php.net/urlhowto.php.

I remember using this at least as far back as 2001 when I was doing PHP development so there is prior art several years in advance of the patent application.

You are correct, that's been in use since 2002. PHP's website CVS shows http://www.php.net/urlhowto.php (the page describing their search system) being first checked in at Sat Mar 23 10:43:25 2002. (See the file in CVS)

You are correct, that's been in use since 2002. PHP's website CVS shows http://www.php.net/urlhowto.php (the page describing their search system) being first checked in at Sat Mar 23 10:43:25 2002. (See the file in CVS)

php.net has had that feature for years. Makes for a very quick way to check the manual.

e.g. http://www.php.net/sprintf

Don't forget one I use frequently: http://www.php.net/patentssuck/

This slide from a talk delivered in January 2003 describes the same idea of searching by URL content (listed under "Interesting Uses"). I don't remember being particularly surprised by the idea at the time, so I'm sure there's considerably older prior art, but this was the first thing that sprang to mind.

(Ignore the date on the top right, which always shows today -- the talk's date of January 22, 2003 is listed on the PHP talk index.)

This slide from a talk delivered in January 2003 describes the same idea of searching by URL content (listed under "Interesting Uses"). I don't remember being particularly surprised by the idea at the time, so I'm sure there's considerably older prior art, but this was the first thing that sprang to mind.

(Ignore the date on the top right, which always shows today -- the talk's date of January 22, 2003 is listed on the PHP talk index.)

The php website has done this for ages when searching functions. I am sure they have been doing it before 2004.

eg.

http://www.php.net/stupid%20patents

Rails is to Ruby as Symfony is to PHP. I've tried Symfony myself and real had a hard time getting my head around it, likewise I'd probably have the same problem with RoR only worse because I'm more attuned to PHP or Perl, I do find that by using the Smarty templateing engine and MDB2 Database API that what I'm working on has shrunk dramatically and is much easier to understand. There are several Perl equivalents on CPAN, that are probably more reliable and mature than the PEAR equivalents in PHP, I assume that the only reason they aren't used more is because embperl is more arcane to use than PHP.

Rails is to Ruby as Symfony is to PHP. I've tried Symfony myself and real had a hard time getting my head around it, likewise I'd probably have the same problem with RoR only worse because I'm more attuned to PHP or Perl, I do find that by using the Smarty templateing engine and MDB2 Database API that what I'm working on has shrunk dramatically and is much easier to understand. There are several Perl equivalents on CPAN, that are probably more reliable and mature than the PEAR equivalents in PHP, I assume that the only reason they aren't used more is because embperl is more arcane to use than PHP.

Rails is to Ruby as Symfony is to PHP. I've tried Symfony myself and real had a hard time getting my head around it, likewise I'd probably have the same problem with RoR only worse because I'm more attuned to PHP or Perl, I do find that by using the Smarty templateing engine and MDB2 Database API that what I'm working on has shrunk dramatically and is much easier to understand. There are several Perl equivalents on CPAN, that are probably more reliable and mature than the PEAR equivalents in PHP, I assume that the only reason they aren't used more is because embperl is more arcane to use than PHP.

Does Java have the equivalent of PHP's eval() function?

all that and more.

try velocity, freemarker or any of a bunch of templating engines if you want to parse a $tokenized string and have variables inserted or macros/functions run from whats in the input.

java as a platform provides all the building blocks you need, plus a wide variety of common libraries. the icing on the cake is the multitude of 3rd party library code ( open source and commercial ) that you can quickly integrate and use for whatever your needs are.

( as an aside, using php's eval() is a dirty way of writing code. http://au2.php.net/manual/en/function.eval.php#75389 for starters )

MDB2 is probably preferable to PDO in at least some situations, since it's a PEAR package, as opposed a PECL module, which should make installation easier on cheap webhosts.

MDB2 is probably preferable to PDO in at least some situations, since it's a PEAR package, as opposed a PECL module, which should make installation easier on cheap webhosts.

I'm not sure if this is specifically what you're referencing, but in case it is, I agree that it was a questionable decision to previously leave it on by default. However, it has changed (if this is what you mean):

http://us2.php.net/register_globals

"Chapter 29. Using Register Globals

Perhaps the most controversial change in PHP is when the default value for the PHP directive register_globals went from ON to OFF in PHP 4.2.0. Reliance on this directive was quite common and many people didn't even know it existed and assumed it's just how PHP works. This page will explain how one can write insecure code with this directive but keep in mind that the directive itself isn't insecure but rather it's the misuse of it.

When on, register_globals will inject your scripts with all sorts of variables, like request variables from HTML forms. This coupled with the fact that PHP doesn't require variable initialization means writing insecure code is that much easier. It was a difficult decision, but the PHP community decided to disable this directive by default. When on, people use variables yet really don't know for sure where they come from and can only assume. Internal variables that are defined in the script itself get mixed up with request data sent by users and disabling register_globals changes this"

There are plenty of very high traffic sites based in PHP. So it is a serious tool.

A lot of that is scripts that load a lot of code that is parsed, loads a lot of other code that is also parsed, and then finally, after 50 to 100 or more files are loaded and parsed, it gets around to actually starting to DO something.

Personally, that's why I avoid PEAR... Any PEAR solution is general enough to work for most people, but far bulkier than a hand-tailored solution, and generally notorious for dividing code out into about 5 bajillion scripts. If you want to generalize something and keep it fast, do it in C and export it as a PHP module like PECL. In any case, the cost of excess mandatory includes can be significantly reduced by a script-caching engine like APC.

Then there's the problems of concurrency, etc., which get worse the more cpus you throw at a problem, which is why throwing more servers into the mix doesn't scale linearly.

Typical PHP apps pretty basic, and pretty easy to parallelize. The "hard" concurrency is all in DB land, and it doesn't matter if 100 different processes are connecting or one process is connecting 100 times; it's going to look the same to the DB (minus TCP overhead, but if you're worrying about TCP overhead, stop using scripting language!). Throwing more servers at the problem will scale it very well, provided the DB is fast enough. It's not the same as more CPUs on a single server; there's much less contention between processes on a server farm than processes on a single megalomonster computer.

A lot of that is scripts that load a lot of code that is parsed, loads a lot of other code that is also parsed, and then finally, after 50 to 100 or more files are loaded and parsed, it gets around to actually starting to DO something.

Personally, that's why I avoid PEAR... Any PEAR solution is general enough to work for most people, but far bulkier than a hand-tailored solution, and generally notorious for dividing code out into about 5 bajillion scripts. If you want to generalize something and keep it fast, do it in C and export it as a PHP module like PECL. In any case, the cost of excess mandatory includes can be significantly reduced by a script-caching engine like APC.

Then there's the problems of concurrency, etc., which get worse the more cpus you throw at a problem, which is why throwing more servers into the mix doesn't scale linearly.

Typical PHP apps pretty basic, and pretty easy to parallelize. The "hard" concurrency is all in DB land, and it doesn't matter if 100 different processes are connecting or one process is connecting 100 times; it's going to look the same to the DB (minus TCP overhead, but if you're worrying about TCP overhead, stop using scripting language!). Throwing more servers at the problem will scale it very well, provided the DB is fast enough. It's not the same as more CPUs on a single server; there's much less contention between processes on a server farm than processes on a single megalomonster computer.

A lot of that is scripts that load a lot of code that is parsed, loads a lot of other code that is also parsed, and then finally, after 50 to 100 or more files are loaded and parsed, it gets around to actually starting to DO something.

Personally, that's why I avoid PEAR... Any PEAR solution is general enough to work for most people, but far bulkier than a hand-tailored solution, and generally notorious for dividing code out into about 5 bajillion scripts. If you want to generalize something and keep it fast, do it in C and export it as a PHP module like PECL. In any case, the cost of excess mandatory includes can be significantly reduced by a script-caching engine like APC.

Then there's the problems of concurrency, etc., which get worse the more cpus you throw at a problem, which is why throwing more servers into the mix doesn't scale linearly.

Typical PHP apps pretty basic, and pretty easy to parallelize. The "hard" concurrency is all in DB land, and it doesn't matter if 100 different processes are connecting or one process is connecting 100 times; it's going to look the same to the DB (minus TCP overhead, but if you're worrying about TCP overhead, stop using scripting language!). Throwing more servers at the problem will scale it very well, provided the DB is fast enough. It's not the same as more CPUs on a single server; there's much less contention between processes on a server farm than processes on a single megalomonster computer.

The same can be said for server loads - page generation is going backwards in terms of cpu usage. I've seen php scripts that end up #including almost 100 other scripts ON EVERY PAGE LOAD!!!

It may brighten your day to discover that a well-optimized site can still include a lot of scripts and avoid latency due to script caching engines like APC. Actually, the best-case scenario for something like APC is a script that performs 0 conditional includes: everything up at the top, always the same, so that it can precompile as much as possible. It's the same notion as using Precompiled Headers in MS Visual Studio to speed up your build time. Rasmus Lerdorf works like a fiend to optimize syscall count in PHP, particularly with APC and initial script loading.

Remember all that about premature optimization being the root of all evil. If you haven't measured the relative cost of all of those includes, you can't make a blanket statement about HOW HORRIBLE IT IS!!!!

Say, a library wrapper for accessing a legacy data source for which there's no scripted library?

I think this is what the ffi extension for PHP is all about

PHP3 to PHP4 was also a big jump. But if you actually look at the backwards incompatibility list between PHP4 and PHP5, it is a very short list of very minor tweaks. I can say with a very good level of confidence that they aren't going affect me at all! OK, I can say this because I already switched, but you see my point.

There have been big steps forward 'under the hood' and with the new object orientation and better scoping... but this is basically all new stuff. Nothing widely used has been removed. I think they will start carefully stripping out the cruft for PHP6

This is a great move I think. php 5 has been out for years, superior and pretty backward compatible to php 4. Many problems in the past with 4.3/4.4 and 5.0/5.1 releases have happend due to the backward compatibility of php 5. I hope this will ease development and result in a robuster solution.

Becasue php5 is already in the wild for years and there is still more than a year of security updates available, I think there should be time enough for migration to php5. I is also not too hard to migrate, I have done this in the last 1-2 years on many sites. There are some really annoying changes in php 5 but the php guys have documented it well [1].

Using the "Migrating from PHP 4 to PHP 5"[2] Documentation was very helpfull and it turned out to be pretty easy (except for scripts/applications which were already ported from php 3 and still were using php 4 backward compatibility "features").

1) http://www.php.net/manual/en/migration5.incompatib le.php
2) http://www.php.net/manual/en/migration5.php#migrat ion5.changes

This is a great move I think. php 5 has been out for years, superior and pretty backward compatible to php 4. Many problems in the past with 4.3/4.4 and 5.0/5.1 releases have happend due to the backward compatibility of php 5. I hope this will ease development and result in a robuster solution.

Becasue php5 is already in the wild for years and there is still more than a year of security updates available, I think there should be time enough for migration to php5. I is also not too hard to migrate, I have done this in the last 1-2 years on many sites. There are some really annoying changes in php 5 but the php guys have documented it well [1].

Using the "Migrating from PHP 4 to PHP 5"[2] Documentation was very helpfull and it turned out to be pretty easy (except for scripts/applications which were already ported from php 3 and still were using php 4 backward compatibility "features").

1) http://www.php.net/manual/en/migration5.incompatib le.php
2) http://www.php.net/manual/en/migration5.php#migrat ion5.changes

"We would still be thankful for RMS though. "

Thank you, Richard!

Thank you, Richard!

Thank you, Richard!

Thank you, Richard!

Thank you, Richard!

Thank you, Richard!

Thank you, Richard!

Thank you, Richard! And happy birthday!

I agree. One example (although not related to CSS) is how many PHP+MySQL examples you'll see where they're using queries constructed at run time and not prepared queries (prepared queries stored procedures). Personally I think that people shouldn't be using mysql_* and should be using something like PDO to make your code a little more database agnostic, but that's just me. Many of the examples you find on the net are just crap tutorials written up by people who are just starting out programming, saw some other really bad tutorial, and wanted to show of their 1337 skillz.

If you want to avoid SQL injection in PHP, one option is to use PDO and especially PDO->Prepare() and PDOStatement->Execute(). Again, not the silver bullet but easy and consistent way to handle weird user input.

If you want to avoid SQL injection in PHP, one option is to use PDO and especially PDO->Prepare() and PDOStatement->Execute(). Again, not the silver bullet but easy and consistent way to handle weird user input.

It's not a shame to admit you know zilch about XSS. But at least use a library/package/class or something which prevents these flaws. For instance for the PHP developers, there is HTML_Form, which includes a unique hidden form field each time a form is generated thus preventing some XSS.

I wanted to discuss this one... I've heard this particular criticism of PHP many times, although I haven't seen any suggestions about what precisely PHP should do to fix this. (Or what precisely is wrong with having a lot of functions in the "core," a term which is also unclear.)

What I see as wrong with having lots of built-in functions:

• It's difficult to remember them. This is compounded by the inconsistent naming, and the inconsistent arguments and return values. It means you have to keep referring to some sort of reference... or just copy-and-paste code from other people like a lot of PHP users appear to do.
• It reduces the set of names that you can use for your own functions, and increases the chance of an accidental collision.

The answer is modularisation. Looking at the long list of functions in the PHP manual, I think that all but a few core groups should be handled in modules that are loaded at run-time. That'd clean things up, but would be yet another backwards-incompatible change to the language. Frankly it'd be easier in the long term to switch to a proper language with a good framework e.g Java (Struts), Perl (Catalyst), Python (Django, TurboGears), or Ruby (RoR). Your code will be clearer and easier to maintain because of the MVC separation and you won't have to fuck around with your language changing underneath you (or be stuck with PHP 4 because your $5.95/mo web host doesn't want the hassle of breaking customer's web sites).

This will help you a lot: http://pecl.php.net/package/apd/ APD, a profiler for PHP

want performance from php?

Dump Apache! its the slowest link!

use Lighttpd + latest PHP 5.2.2 + APC

which for a long time didn't even support prepared statements

Let's take an example: http://viewcvs.php.net/viewvc.cgi/php-src/ext/oci8 /oci8.c?revision=1.1&view=markup - added 8 years ago. Prepare? Yes. Bind? Yes. For 8 years. Now that's what I call supported for a long time.

The problem is more with this database named after a child, which didn't support any of the advanced features for years.

Actually, it's been released for a while now.

PHP 5 does natively via PDO, and PHP 4 (and 5) does via PEAR's MDB2 (older version: DB). There is also ADOdb which has a very similar API to Microsoft's ADO RDBMS API (acronym overload!).

The availability of robust packages like those still doesn't stop newbie (and veteran) PHP programmers alike from just using the raw MySQL API subset known as the mysql_* functions (which were deprecated in favour of the newer MySQLi functions/objects that also support prepared statements) along with occasional use of addslashes().

PHP 5 does natively via PDO, and PHP 4 (and 5) does via PEAR's MDB2 (older version: DB). There is also ADOdb which has a very similar API to Microsoft's ADO RDBMS API (acronym overload!).

The availability of robust packages like those still doesn't stop newbie (and veteran) PHP programmers alike from just using the raw MySQL API subset known as the mysql_* functions (which were deprecated in favour of the newer MySQLi functions/objects that also support prepared statements) along with occasional use of addslashes().

PHP 5 does natively via PDO, and PHP 4 (and 5) does via PEAR's MDB2 (older version: DB). There is also ADOdb which has a very similar API to Microsoft's ADO RDBMS API (acronym overload!).

The availability of robust packages like those still doesn't stop newbie (and veteran) PHP programmers alike from just using the raw MySQL API subset known as the mysql_* functions (which were deprecated in favour of the newer MySQLi functions/objects that also support prepared statements) along with occasional use of addslashes().

PHP 5 does natively via PDO, and PHP 4 (and 5) does via PEAR's MDB2 (older version: DB). There is also ADOdb which has a very similar API to Microsoft's ADO RDBMS API (acronym overload!).

The availability of robust packages like those still doesn't stop newbie (and veteran) PHP programmers alike from just using the raw MySQL API subset known as the mysql_* functions (which were deprecated in favour of the newer MySQLi functions/objects that also support prepared statements) along with occasional use of addslashes().

If the attacker can supply their own code, they can just call popen() or system() and dispense with all the hoopla required to compermise the worker and inject shellcode.

Limit the files that can be opened by PHP to the specified directory-tree, including the file itself. This directive is NOT affected by whether Safe Mode is turned On or Off. When a script tries to open a file with, for example, fopen() or gzopen(), the location of the file is checked. When the file is outside the specified directory-tree, PHP will refuse to open it. All symbolic links are resolved, so it's not possible to avoid this restriction with a symlink.

Shot down?

Yep. They were removed from 5.0.0 beta 2 for various reasons.

Oh, you forgot:

5,343 built-in functions, assuming all the standard modules are installed. By comparison Python has 71. In other words, you have to keep track of about 75 times the number of name collisions when dealing with PHP versus Python.

This could be almost instantly fixed if they'd add namespaces to PHP, but that keeps getting shot down.

For multi-threading, install a shared-memory cache, like apc, eAccelerator, or mmcache -- or use an in-memory table in your RDBMS. Now, you can spawn background tasks and monitor their progress or receive return values through the cache. You can even start a task as a server and keep it running indefinitely with set_time_limit(). I do plenty of unicode apps as UTF-8, and haven't had problems yet. If you're talking about UCS-2, then you have a good case. It's in development, but it's for PHP 6. Honestly, I'll probably switch languages before v6, based on all the other crap they're talking about throwing in. Version 5 is already getting pretty bloated, and it's only marginally faster than Java.

Here's the utility function I use to spawn background threads (like, sending a thousand customized newsletters or updating hundreds of thousands of database rows). The background process can either lock a file or create some shared-memory structure to indicate its progress, and you can return immediately and end the script before it's done running. The nice prefix is optional.

function fork($shellCmd) {
exec("nice $shellCmd > /dev/null 2>&1 &");
}