Slashdot Mirror

You should look into PDO,
database abstraction with preparation of statements et al ([code example])

I code PHP for a living and I agree with everything you say. For logic/presentation seperation there is Smarty, but its definately not something a lot of PHP developers know about.

I haven't seen a whole lot of PHP 5 either, but from what i have seen they mostly concentrated on fixed a lot of the OO problems. Which is good but I was hoping they would address some of the more serious (IMHO) problems with the underlying language (adopting a standard naming scheme for functions, maybe creating some namespaces, having real arrays ... etc.)

Actually, if you have a look at the documentation for mysql_escape_string, you'll see that it is depreciated, and you should now be using mysql_real_escape_string instead.

Gotta love PHP...
</pedant>

Actually, if you have a look at the documentation for mysql_escape_string, you'll see that it is depreciated, and you should now be using mysql_real_escape_string instead.

Gotta love PHP...
</pedant>

FYI PHP 5.1 comes with a standard DB connectivity library called PDO. You can also install it on PHP 5.

http://www.php.net/pdo

My only real gripes with PHP are the lack of a standard DB connectivity layer like JDBC.

You mean like PDO?

You mean like PHP-GTK?

I like better the ability to have interfaces, standards, Struts, lots of things that make Java better for developer teams.

interfaces (i assume you mean the OO type) : http://www.zend.com/php5/articles/engine2-php5-cha nges.php

Struts = Smarty: http://smarty.php.net/ (and this is about 100 times easier to configure and deploy than Struts)

Then don't code in the presentation layer. It's not where it belongs anyways, most larger php projects are separated, and any competent programmer will separate it anyways. Yeah, you can do bad code in PHP, but you can do it in other languages. See Obfuscated C contest. Or java's famous: string.operand(string.toUpper(blah.toBlah(blah.mak eDisappear(blah.makeRandomText(crap)))));

Don't tell me that's easier to understand than badly written PHP. But no, you don't have to code in the presentation layer, and we enforce that where I work.

However, the real strength of these systems is not in themselves; they are built on a superb platform base which provides Threading, IO, Networking, Graphics, Db access, i18n,and all the things a programmer might ever require. PHP doesnt have anything remotely similar, as far as i can see.

OK, this is a troll if I ever saw one and may I be damned for feeding one but here it goes:

Go look at PEAR and the PHP manual index and then tell people PHP doesn't have a platform offering all those.

However, the real strength of these systems is not in themselves; they are built on a superb platform base which provides Threading, IO, Networking, Graphics, Db access, i18n,and all the things a programmer might ever require. PHP doesnt have anything remotely similar, as far as i can see.

OK, this is a troll if I ever saw one and may I be damned for feeding one but here it goes:

Go look at PEAR and the PHP manual index and then tell people PHP doesn't have a platform offering all those.

And because I'm bored and I like PHP, my reply to all of the above:

* PHP sucks.

PHP has functions for practically anything you can imagine. Of course, I'll get into why it doesn't suck in the replies below, as this is a bit too general.

* PHP is for n00bs.

PHP is for developers who want to get something done quickly. The syntax is very easy to learn, and variables are loosely typed, but in my experience this doesn't mean that the language is flawed; it means that one can code up something without having to worry about unnecessary things like pointers, variable conversion and the like. And to be honest, in website scripting I've never come across a need for more advanced syntax than PHP provides in my five or more years of using it.

* PHP is usually poorly written.

This, unfortunately, is usually true. Because PHP is easy to use, it is often used by people who don't want to worry about writing good code either. But like everything else, there are varying grades of professionalism. PHP *can* be written well, it's just a case of taking the time to do so.

* PHP is a scripting language and you can't do anything but write web pages with it.

Scripting language, yes. But it most certainly can be used for things other than websites.

* PHP sucks because the function names are inconsistent.

True, but this is why one has a manual. I've never been all that concerned about it.

* PHP is slow.

Actually, it's really not. Take a look at this comparison between different CGI modules for Apache: PHP actually outdoes Perl here.

* PHP isn't capable of working in a real enterprise.

I haven't had experience with integrating PHP into an "enterprise" situation personally, but I'll refer you to Zend's Enterprise PHP page for various reasons why PHP is indeed ready for the enterprise.

* Real coders use Perl.

Real coders use the tool that best fits the problem.

* PHP doesn't scale.

Now THIS is something I can definitely refute. I work for a company that creates mods for a PHP / Smarty-based online shopping cart known as X-Cart and I can tell you, PHP scales wonderfully, otherwise stores wouldn't use it as a base of their business operations. X-Cart is on the order of hundreds of thousands of lines of PHP code, and very commonly has tens of thousands of customers accessing it concurrently.

And yeah, I know you were joking, but hey, I was bored. ;^)

Yes, it's quite a shame that you can't do object oriented programming in PHP.

Sure, that's what php-gtk (http://gtk.php.net/) is all about :)

Actually, php-gtk is very useful when you have an existing PHP web app that you want to port into a desktop app. It's a great project, but is definitely not meant for large-scale apps.

I work with PHP and Java (and JSP and XML and enough other acroynms to choke a hippo). Andressen's comments seem so clearly aimed at server-side Java. PHP doesn't do client side, though there are projects underway like GTK and WinBinder. But still... Java was supposed to kill C, and it didn't. PHP won't kill Java either.

You're pretty much correct. PHP is a lot closer to JSP or ASP than Java, and yes, it can violate separation of logic and presentation. However, you can use the Smarty templating library to separate code and presentation (and I recommend this to anyone learning PHP, because embedding PHP in HTML makes for very sloppy and nigh unreadable code).

About 22 million Web sites employ it

Well, of course. PHP works for free.

Wondering where the '22 million web sites' comes from? http://www.php.net/usage.php.

That's a good MS promoter!
If it doesn't run on Windows, it's Jerry-rigged, and pushing companies to write cross-platform software would just be pushy.

Here's a little-known-fact about linux: Many major software manufacturers write software that runs on linux. The ones that don't, are doing it based on marketing strategies. If the market changed, so would their coding practices. As a business owner, I do not have the type of money to back up a Microsoft platform, and I also cannot justify using the software due to quality and corporate tie-ins. When I'm bigger, maybe I'll dig myself a hole and dive in head first (Microsoft said they already have it started for me whenever I feel like jumping).

Honestly, if Adobe made their software for Linux, then I would guess at least another 29 million people would switch over to linux. I just love how software like Blender 3d, Firefox, Thunderbird, OpenOffice.org, Zend Studio, Star Office, MySQL, Oracle, Apache, PHP, and many many others all work on Windows and Linux, and oftentimes MacOSX, but lazy companies like Adobe/Macromedia, Autodesk, and most gaming companies choose to single out one or two platforms to target simply because of marketing strategies.

Microsoft has chosen time and time again to refuse to implement global standards simply because they want to lock people into using their software. Your post proves that their marketing strategy works.

Also keep in mind that hardware working with the operating system says more about the hardware manufacturers than the operating system. Microsoft has been known to strongarm hardware manufacturers to not create linux drivers, and many hardware manufacturers are just too lazy to work with the linux community.

So while Linux, being about half the age of windows, is still lacking in a few areas, it is still more stable and provides enough features for me to use. I still keep a windows box around at work for troubleshooting other users' microsoft office problems, and for running the Adobe Creative Suite, but you can bet I'll be formating every windows box I own as soon as Adobe releases Linux binaries. (considering how closely related OSX and Linux are, I still don't understand why they don't make a linux port)

In short, if industries really did shift to linux, companies that write software wouldn't hesitate to change as well. It is our fear of something different that keeps us on Windows, and keeps software developers from writing linux code, resulting in jerry-rigged solutions like Firefox, Thunderbird, PHP, Apache, Oracle Enterprise server, and others. (note the sarcasm)

"Unless I've misunderstood the concept, this new provision, if implemented (say) in MySQL, would require a website to disclose all its source code to anyone who can access it"

From the article (emphasis mine):

Stallman said developers may be encouraged to add a command to their GPL-licensed Web application that lets users download the source code. The inclusion of this command in modified versions of the program will then be enforced by an additional clause in GPL 3.

"We're looking at an approach where programs used (on a public server) will have to include a command for the user to download the source for the version that is running," Stallman said. "If you release a program that implements such a command, GPL 3 will require others to keep the command working in their modified versions of the program."

For example, look at the website for PHP and, specifically, the bottom. There is a link that shows me the source for that page (and further links to an index of the whole source). Let's assume that, for the moment, that the code that's behind their website is offered under the GPL. If so, I could, under GPLv2, copy that code, create my own website with it, make modifications as I see fit, and remove the link to download source.

The proposal, for GPLv3, is that if you make a program with a web interface and include a link to the current code behind that page, then anyone who takes the code must leave that link intact. Since MySQL doesn't have a web-based interface, moving it to the GPLv3 would not force websites that use MySQL to release any code - even if they modify MySQL directly for their use. It would, however, mean that if PHPMyAdmin went to GPLv3 and added a link to the source of the current version, users wouldn't be allowed to remove it. And, if they make any modifications, those changes would be included in that link.

Speaking of PHPMyAdmin brought an important consideration to bear: passwords. Often, especially in PHP based scripts, the username/password to the database and other resources is kept in clear text in a php file. Would redacting sensetive information, such as passwords, from any source download link violate the GPLv3? I hope not, and I don't think so (because such redactions wouldn't inhibit the otherwise normal operation of the software).

What would be nice would be a register within a PHP script that simply identified which functions were called. In the meantime, this works well for me...

What would be nice would be a register within a PHP script that simply identified which functions were called. In the meantime, this works well for me...

REGISTER_LONG_CONSTANT("SYSCALL_EXEC", 1, CONST_CS | CONST_PERSISTENT);

There have been bindings for PHP for a few days, now.

S

http://pear.php.net/package/DB

A little OT, but in reference to your PHP-related comments:

Even though "" == 0 is true,
"" === 0 is not true ("" !== 0). This is VERY useful in various respects.

I develop my PHP apps with E_STRICT set as the reporting level, (http://us2.php.net/error_reporting) and use a library I found that stores every PHP error/warning in an array to display it at the end of the document (in my case, inside a JavaScript popup). This way, I get warnings for using undefined variables. If you want some code, tell me...I don't have it on my site, but if there is demand for it, I can put it there.

• You do realize you can print/echo multiple lines of output at once in PHP? I also recommend using "print" for normal stuff and "echo" for debugging - that's just my preference though.
  
• You also seem to program very linearly (I see a lot of stuff that should be functioned off).
• Endless "if" statements can be written more clearly with the "switch" statement.
• Stay consistant with HTML case. I would suggest sticking with XHTML lowercase for tags.
  
  

  If you want to get the most out of AJAX, pass the information back to the client in a compact XML form. I recommend a format with one element per record with attributes for record columns. The whole point of AJAX is to keep the information tyou pass for each request between the client and server to a minimum. Of course, I couldn't fin the XMLHTTPRequest declation in your code either.

"I looked into writing a METAR-parsing library at one point."

The PHP PEAR already has one of these: http://pear.php.net/package/Services_Weather

Smarty is a very good templating system.

http://smarty.php.net/

"Database abstraction? Why would anyone need that?"
http://php.net/pdo

From the top of that PDO page you sent me to:

Warning

This extension is EXPERIMENTAL. The behaviour of this extension -- including the names of its functions and anything else documented about this extension -- may change without notice in a future release of PHP. Use this extension at your own risk.

Re: namespaces. How old is PHP? And they're only now getting around to it? Younger languages seem to have them. Why has PHP, a very popular language with an active community, taken so long to implement them if for no other reason than they didn't think it was that important.

Re: design patterns. I see that those have come around since PHP5 was released, now that it has real objects. I also notice that there have been a lot of comments from PHP developers that PHP4 was sufficient, and they saw no need to switch. Wake me when PHP design patterns become relevant, ie. are widely adopted.

As for security... *sigh* From the page you linked:

For real security you should consider providing chrooted jail's for your users.

Good advice, no matter what the product or language. Next quote:

Remember that security risks often don't involve months of prep work or backdoors or whatever else you saw on Swordfish ;) In fact one of the bigges newbie mistakes is not removing "<" from user input (especially when using message boards) so in theory a user could secerely mess up a page or even have your server run php scripts which would allow them to wreak havoc on your site.

And here we have a failure of the model. This is yet another classic example why logic should not be embedded in your presentation layer.

best bet is to build php as cgi, run under suexec, with chroot jailed users. Not the best, but fairly unobtrusive, provides several levels of checkpoints, and has only the detriment of being, well, kinda slow. 8)

"Kinda slow" being an understatement. "Kinda slow" guarantees that most PHP users will never use a chroot environment. So we're back to square one.

If your PHP pages include() or require() files that live within the web server document root, for example library files in the same directory as the PHP pages, you must account for the possibility that attackers may call those library files directly.

Any program level code in the library files (ie code not part of function definitions) will be directly executable by the caller outside of the scope of the intended calling sequence. An attacker may be able to leverage this ability to cause unintended effects.

The most robust way to guard against this possibility is to prevent your webserver from calling the library scripts directly, either by moving them out of the document root, or by putting them in a folder configured to refuse web server access. With Apache for example, create a .htaccess file in the library script folder with these directives:

Order Allow,Deny
Deny from any

And beginners are equipped to follow -- or even understand -- that last requirement. It's a shame there isn't a policy manager or programmatic sandbox for the code. That would tighten security by default. But wait. I forgot. It will restrict people's programmatic freedom of expression or some such nonsense.

Here is the point that a lot of folks don't seem to get. It is possible to code assembly robustly, securely, and extensibly. However, it is extremely difficult to do so for any non-trivial apps. If more than 75% of PHP coders do not understand what is necessary to secure their environment, I blame the language, not the coders.

Take an example from Java applets -- not the language, the VM in general, or any real or perceived speed problem

Does PHP have the equivalent of CPAN?

Yes, it's called PEAR: The PHP Extension and Application Repository.

"Database abstraction? Why would anyone need that?"
http://php.net/pdo

"Namespaces? Why would anyone need that?"
it's coming

"Design patterns? What are those?"
http://php.net/language.oop5.patterns
http://phppatterns.com
php|architect's Guide to PHP Design Patterns

"Security? If it's a problem, we'll fix it later."
http://php.net/security
(Almost all of PHP's historical security problems have been third-party.)

S

"Database abstraction? Why would anyone need that?"
http://php.net/pdo

"Namespaces? Why would anyone need that?"
it's coming

"Design patterns? What are those?"
http://php.net/language.oop5.patterns
http://phppatterns.com
php|architect's Guide to PHP Design Patterns

"Security? If it's a problem, we'll fix it later."
http://php.net/security
(Almost all of PHP's historical security problems have been third-party.)

S

"Database abstraction? Why would anyone need that?"
http://php.net/pdo

"Namespaces? Why would anyone need that?"
it's coming

"Design patterns? What are those?"
http://php.net/language.oop5.patterns
http://phppatterns.com
php|architect's Guide to PHP Design Patterns

"Security? If it's a problem, we'll fix it later."
http://php.net/security
(Almost all of PHP's historical security problems have been third-party.)

S

PHP6 will essentially be PHP5.1 + unicode which is the deciding factor for me..

The PHP manual, which is a docbook - so you could call it anti-wiki ;), has a chapter about the CLI stuff: http://php.net/manual/en/features.commandline.php - or you should install the man page on Mac OS X I have one. Or you could just call php with -h - -v gives you BTW the version and tells you which SAPI it's been compiled with (cli, cgi, fcgi).

The syntax $x = &foo(); would call a normal function called foo and assign a reference to the return value $x. That's already a valid syntax, thus it can't be used for a new feature. And it's the way you handle returned objects in PHP4. As Marcus Börger said: "If your OO code doesn't work , throws some amps around. If it still doesn't work user more" ;) This stuff has been solved in PHP5.

The variable function call syntax has an other advantage - it can also be used for method calls. See http://php.net/manual/en/language.pseudo-types.php #language.types.callback for information about callbacks (that's how it's called in PHP).

If you've more questions about PHP don't hesitate to ask =)

b4n

The PHP manual, which is a docbook - so you could call it anti-wiki ;), has a chapter about the CLI stuff: http://php.net/manual/en/features.commandline.php - or you should install the man page on Mac OS X I have one. Or you could just call php with -h - -v gives you BTW the version and tells you which SAPI it's been compiled with (cli, cgi, fcgi).

The syntax $x = &foo(); would call a normal function called foo and assign a reference to the return value $x. That's already a valid syntax, thus it can't be used for a new feature. And it's the way you handle returned objects in PHP4. As Marcus Börger said: "If your OO code doesn't work , throws some amps around. If it still doesn't work user more" ;) This stuff has been solved in PHP5.

The variable function call syntax has an other advantage - it can also be used for method calls. See http://php.net/manual/en/language.pseudo-types.php #language.types.callback for information about callbacks (that's how it's called in PHP).

If you've more questions about PHP don't hesitate to ask =)

b4n

Watch for array_merge calls. It's a lot pickier now about what it will accept. Be sure to look here for the whole story, but I found that in the process of tidying up my code to accommodate the change, I refactored several sections of code to avoid the need for array_merge entirely. Hint: Do absolutely everything you can in SQL instead of in your code. This goes for any language. The performance boost will be noticed both on old hardware and on high-load installations.

Anyone doing anything more than that on the web has to know something besides PHP since doing anything complex in PHP simply isn't very easy at all.

Having done some rather large and complex projects with PHP, your comment leaves me very curious.

What complex thing(s) is/are difficult to do in PHP? (I'll draw the line at stuff like rendering 3D, since the language clearly isn't meant for stuff like that)

I've had excellent results

1) Developing semi-distributed, (borrowing a buzzword) RIA type application using PHP-GTK.

2) Read headers from MP3s

3) Forked it into a daemon to process TCP socket calls with a home-rolled protocol,

4) Parsed Apache and Sendmail log files,

5) Run system administration,

6) Build a large-scale backup system

and much more, as well as the usual "I built a weblication using LAMP". I fail to see where PHP is particularly limiting in general programming...

foreach ($_GET as $s=>$v) {
${$s}=$v;
}
foreach ($_POST as $s=>$v) {
${$s}=$v;
}

This is the most rediculously stupid comment I have ever seen. It makes a series of statements as fact, without any proof.

It also makes claims of a solution which is incomplete. WTF? 'Would they even be willing to go so far as to demand that the PHP developers include functionality to severely limit the ability of faulty scripts to run?'

Demand to make C programs unable to be hacked.
Demand that perl programs are unable to be hacked.
Demand that assembly programs are unable to be hacked.

How about looking at the reputation of the group developing the software you morons install? If there's been tens or hundreds of vulnerabilities in the product you want to install, expect more!

Also, see See http://us2.php.net/features.safe-mode

Sounds like you just need to get PHP and Mysql and make it database driven... then you could update the website from the web. Also, there are WYSIWYG editors made in javascript that make editing content similar to word. thats what i use at my site... or you could slap php-nuke on it like i did on my site

If all of the emails are stored in an imap account then you could access this programatically using PHP's Imap functions. I do the same thing using a cron job to check an email account every 5 minutes on my site, if theres a new mail it looks to see if it has an image attachment and if it has automatically posts it online for me.

Information about PHP's Imap functions can be found at http://uk.php.net/imap.

I'm not entirely sure if this is the kind've thing you are looking for, but this is probably how I would deal with the problem.

Regards,

Grant

Dear god, why? You mean this function can return a string or a Boolean value? If I had to use PHP, that would make me cry. Dynamic typing is nice and all, but abusing it like that in a standard API is just awful.

I actually like PHP for large-scale web apps.

I can't help but think that everybody who says PHP scales simply has never gotten to know Java before. PHP was started as a hack and it's had new features tacked on ever since. Its extensions all have different function naming conventions and argument ordering (pop quiz: which parameter to is_array() is the needle, and which is the haystack? What about strstr()?). PHP4's objects copy themselves at the slightest provocation, leading to all sorts of problems. And while PHP's arrays are handy, they're nothing compared to Java's incredible Collections.

Obviously, the developers are aware of this, and along comes PHP5. But looking at The changes since PHP4, all you'll find are a whole bunch of changes which make PHP more like Java (oh, and PHP's "unique" overloading and object iteration features, which are truly bizarre).

I dunno about you, but the fact that PHP's developers are trying to make it more and more like Java leads me to suspect that Java has done something right.

I interpret your post to say that you worked on your 20k-line project alone; try working in a team in both PHP and Java and you'll understand why people say PHP doesn't scale.

It's all here. :)

Of course it's not perfect. The DB classes should be a part of the PHP core libraries, not implemented in PHP themselves.

Here is PHP's problem:

The guy who started the whole thing hates programming. So PHP was a simple macro language for knocking together Personal Home Pages. But then, people who were too lazy/stupid/whatever to learn a real language and recognise PHP's faults started to use it, and started buliding on it... and it grew, and grew, and now we have what we have, enormous inefficient and insecure warts and all.

Of course, your most important ingredient is this baby right here: the external web service. You can get it in a can but to really do things right, you gotta strangle yourself a fresh one.

We're going to sync with our outside web service using a simple SOAP client, written in whatever language you prefer, and setting the time. (Your users will get their time from you via NTP still, of course.) This isn't required, but for that fresh BAM! taste, it's recommended. Mind the delay calculations if you're writing the client side of it yourself, the WWWait will have a little bit more effect here depending on your setup. If you want to make it quick and dirty, there's no reason to go through the SOAP/WSDL hoops, the point is having it on a known port and piggybacking across HTTP's fame and success, and then sleeping with its girlfriend, and stealing her wallet on the way out. BAM!

Lets not forget that PHP has the worst security history of any language, there are constant exploits and there's nothing you as a PHP user can do about it.

Constant exploits? For PHP, or for crapply-written content management systems (ahem, phpnuke) that happen to be written in PHP?

CERT has issued two advisories for PHP itself: CA-2002-05 and CA-2002-20. Looking through the changelog I see only a handful of security fixes.

Like most languages, it's possible to write unsecure code. I've seen code that executes stuff on the command line, right from a GET string. It's just as possible to write secure code.

One problem with PHP is it's a simple language, and a lot of beginners with no experience pick it up and can use it to write applications. Knowing nothing about software development, or security issues, they tend to write bad, insecure code. This has nothing to do with the language, it simply has to do with the developers. If python or ruby came into incredibly widespread use (ie, available on pretty much any hosting account you can buy, like PHP is), then you'd probably see the same thing happening. It doesn't say anything about the languages, it's simply a matter of inexperienced developers writting bad code.

In PHP, a character is the same as a byte, that is, there are exactly 256 different characters possible. This also implies that PHP has no native support of Unicode.

"Isn't if(false!==strpos( the same as if(strpos(. If something is not false, it must be true, right?!"

Strpos returns the position at which the text is found. If the string is found at the first (0th) character, strpos returns 0

If the string is not found, strpos returns false

You can test whether something is the same type and value by using the 3-character comparaisons === and !==. 0 is an integer, and false is a boolean, which means that they're not equivalent. 0==false, but 0!==false.

See comparisons, and note that this only applies to PHP4 and later.

in php its no big deal to make sure that anything you stuff in a db is safe - just do an $valueToStore = htmlentities($valueFromPoster). So either do the same in perl, or convert to php.