Wicked Cool PHP 131
Michael J. Ross writes "Web developers familiar with a particular programming language, such as PHP, typically turn to books and forums for assistance only when they confront a specific problem that they believe has probably been encountered by many of their peers in the past, and who have published their answers in print or online. Hence the growing popularity of programming "cookbooks", which eschew flowing narratives in favor of self-contained problem descriptions and solutions. One example of a book that combines both styles is Wicked Cool PHP: Real-World Scripts That Solve Difficult Problems, by William Steinmetz with Brian Ward." Keep reading below for the rest of Michael's review.
Published by No Starch Press on 9 February 2008, under the ISBNs 1593271735 and 978-1593271732, Wicked Cool PHP aims to provide the reader with a wide-ranging collection of complete PHP scripts and code fragments that solve specific problems frequently encountered by PHP coders. It is not intended for explaining the fundamentals of PHP, but assumes that the reader already understands the basics of the language. The book covers PHP versions 5 and 6. On the book's Web page, visitors can purchase it online, download a sample chapter (Chapter 4: Working with Forms), and download most of the sample code.
Wicked Cool PHP: Real-World Scripts That Solve Difficult Problems | |
author | William Steinmetz with Brian Ward |
pages | 224 |
publisher | No Starch Press |
rating | 5/10 |
reviewer | Michael J. Ross |
ISBN | 978-1593271732 |
summary | Yet another PHP book that presents a variety of topics through sample code. |
The book's material is organized into a dozen chapters, covering a range of topic areas: some simple scripts; configuring PHP; PHP security; forms; text and HTML; dates; files; user and session tracking; e-mail; images; using cURL to interact with Web services; and three intermediate projects. A brief appendix shows the MySQL commands for creating the product_info table used in many of the book's scripts. The book's back cover claims that it offers 76 scripts, but at least one section (#69) does not contain a script.
The first chapter is titled "The FAQs of Life — The Scripts Every PHP Programmer Wants (or Needs) to Know." That's quite a claim, unfulfilled by the chapter's material, which covers only seven narrow topics, such as how to include another file in a script (require_once) and how to print an array (print_r). Furthermore, there is no common theme for the scripts chosen, aside from their addressing questions that one of the authors — who is not identified — sees repeatedly in PHP forums and discussion groups. Some are extremely basic (e.g., print_r), while others address topics that are far more advanced and deserving lengthier treatment (e.g. templating your site with Smarty). That last topic would have been much better presented as an intermediate project in the book's final chapter.
Configuring PHP is an area that can prove perilous for programmers who are new to the language, and are, for whatever reason, having difficulty setting up PHP on their home Web server. For such individuals, Chapter 2 should prove quite useful, because it offers a clear overview of how they can configure their own PHP installations to match their needs. Some of the configuration advice could be a lifesaver, depending upon the reader's circumstances — such as the information on using open_basedir to limit directory access to PHP (and energetic hackers).
However, on page 20, when the authors provide advice on how the reader can find the php.ini file, they suggest that Windows users should look in "C:\php." Actually, the default installation file path is "C:\Program Files\PHP" (unless the reader has altered the value of ProgramFilesDir in the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion key in their Windows Registry). They urge the reader to delete any phpinfo() script, for security reasons. But having such a script on a remote server could be quite valuable to the reader, at some point in the future; so it would be wiser to simply rename it, assuming that the reader has not allowed hackers to list file names on his or her Web server.
Several times in the book the authors advise the reader to set the error_reporting configuration option off for production servers — as well as for development servers lacking firewalls — so hackers and others do not see system information contained in error messages. But error_reporting is best used for specifying the level of error reporting, while the display_errors configuration option is best used for disabling the display of those errors to the site visitor. Errors should still be recorded in the Apache error log, so the developer can better diagnose what happened on a production site.
As with most first editions, this one contains several errata: "phpinfo()can" (page 21), "data to encrypted" (page 42), "six years" (page 55; should be 10 years, to match the code), and "timestamp() function" (page 82; should be "time() function").
In any book, a sizable number of minor flaws will prompt the careful reader to begin questioning the editing of the book. This is especially true when encountered in the first paragraph of the first page of the Introduction: "stumbled on to," which should instead be two words. But it goes beyond just issues of line editing — to a question of judgment. That very first page also contains "After you calm down," which is too flippant for what should be a professional work, as are other instances: "living hell" (page 4), "hash-ish" (page 40), and "Mac users... [like] to buy expensive gadgets for the sole purpose of looking stylish" (page 113). The authors frequently use the term "I" without specifying which author is being referred to; presumably it is the first author listed. On page 64, they state that they had previously mentioned the === operator, but I cannot find it anywhere, and neither could whoever created the book's index.
In the sample code, the authors use double quotation marks — instead of single ones — for most of the strings, few of which contain variables. This slows down the PHP interpreter by forcing it to check for variables within the strings, to be interpolated. Moreover, they are not consistent in the usage — occasionally switching over to single quotes instead, for no apparent reason. The same is true of in-line comments, which switch back and forth between Java and C styles.
The code in general is not entirely consistent throughout the book, e.g., using print() in most cases, but echo() in the remaining ones, with no explanation as to why. Perhaps this is the result of having two authors. Most HTML tag names are in lowercase, but a couple are in uppercase.
Some of the book's code appears invalid. For instance, on page 5, one of the statements (abbreviated here), echo "$row[product_name]," generates two errors: "unexpected T_ENCAPSED_AND_WHITESPACE" and "Use of undefined constant key — assumed 'product_name'." The correct code would be: echo "{$row[ 'product_name' ]}." On page 41, $cipher is set to the string "MCRYPT_SERPENT_256," which generates an error, and probably instead should be set to the constant MCRYPT_SERPENT, which works fine. $mode is set to the string "MCRYPT_MODE_CBC," but that should be a constant as well. On page 72, the regex pattern for matching HTML anchor tags does not match an entire opening tag, but just a portion of it. In the downloadable code for section #68, getpage.php fails because "<?" should be "<?php." Readers shouldn't have to debug a book's code just to get it to run without error. Did no one test the sample code before publication?! In the code for section #71, mapdemo.php generates index errors when run without any GET parameters, and does not generate a map when values are entered in the form.
Some of the code may work in certain circumstances, but not in others. For example, on page 70, the pipe character (|) is recommended as a substitute for the forward slash (/) for regex patterns containing many such slashes. But the pipe character is a very poor choice, because it has a special meaning in regex patterns, namely, as the 'or' operator, and thus cannot be used for any pattern that needs to use that operator. In section #49, calculate_time_difference() fails if one or both of the timestamps is the epoch time (time zero). In section #61, get_ip() assumes that two $_SERVER keys are set, and fails when they are not.
Some of the code works but can give beginners the wrong impression. For instance, on page 25, the authors present a configuration setting (incorrectly referred to as an "extension"): ini_set(max_execution_time, "240"). But max_execution_time is not placed in quotation marks. Even though this does not cause an error, a newbie may do the same with ini_get(), and become confused as to why PHP then (rightly) complains. (One could argue that PHP should also flag the ini_set() call as erroneous.) Section #50 could mislead newbie programmers into using that multi-line script instead of PHP's file_get_contents(). Section #51 similarly re-creates the wheel, namely, file_put_contents().
Lastly, some of the code, comments, and variable naming choices are quite puzzling. For instance, in section #30, validate_cc_number defines a variable as $false = false, but this "variable" never gets changed in the rest of the script. That is what constants are for. In the downloadable time difference scripts for Chapter 6, we find "print abs(5 — 62);" with no apparent purpose. In timediff.php, calculate_time_difference() checks for divide by zero errors for a variable that is never used as a denominator.
Unlike most computer programming books, this one has no acknowledgments of any technical reviewers. Given all of the problems in the code, it is possible that there actually were no technical reviewers, though it is difficult to imagine any reason why a publisher would choose that unwise route.
In terms of formatting of the material in the book, most of the left-hand pages (the even-numbered ones) have the page contents shifted too far to the right, almost running into the crease of the book, and leaving a glaring amount of wasted whitespace in the left-hand margin. The only exceptions are on pages 163, 164, and 172, where portions of code awkwardly jut out into the left margin.
The downloadable code archive is quite flawed, and a fair amount of the code needs to be cleaned up. For example, getpage.php contains a lot of redundant code. Much of the sample code in the book is not included in the archive; incredibly, this includes some of the largest scripts, such as the Smarty code in Chapter 1 and the credit card processing code in Chapter 4. In fact, the archive is missing the code for two entire chapters (2 and 3). Oddly enough, at least a couple scripts in the archive are not mentioned in the book. The archive needs a complete overhaul, including the cleanup or elimination of seemingly leftover scripts such as foo.php (three instances) and captcha_old.php.
On the positive side of the ledger, the book contains information that would be of interest to all levels of PHP programmers. For instance, readers who are just barely familiar with the language will benefit from the discussions concerning superglobals, form input security, date and file manipulation, and how to save user information with sessions and cookies. More advanced developers may profit from the discussions on encryption, PHPMailer, captchas, Web services, and other topics generally found later in the book.
In addition, many of the sections include a special subsection titled "What Can Go Wrong?," in which the authors consider potential problems with the code or overall approach presented in that section. Undoubtedly other technical books provide such information, interwoven with the main narrative; but explicitly identifying potential pitfalls is a worthy practice — one that we can only hope to see in other programming books in the future.
At 224 pages, it is a relatively slim volume, but contains a fair amount of useful information relative to its size — a pithiness welcome in the world of computer books. (Fortunately, the trend in the technical publishing world has shifted away from tomes sometimes exceeding 1000 pages that are padded with poorly-edited material shoveled in by multiple authors.)
Yet all in all, Wicked Cool PHP is largely disappointing. It contains no PHP scripts that could be considered "wicked cool." Moreover, the aforementioned code problems clearly call for an improved second edition, including a complete revision of the downloadable code archive. On the other hand, Wicked Cool PHP touches upon a number of key topics in PHP programming, with minimal fluff, and gets right to the point.
Michael J. Ross is a Web developer, writer, and freelance editor.
You can purchase Wicked Cool PHP: Real-World Scripts That Solve Difficult Problems from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
O'Reilly's PHP cookbok preferable (Score:5, Informative)
Re:O'Reilly's PHP cookbok preferable (Score:5, Insightful)
Re: (Score:1)
Re:O'Reilly's PHP cookbok preferable (Score:5, Funny)
Developing a commercial website which is problematic for 25% of its potential visitors is stupid and unacceptable. Come off of your Microsoft bashing mountaintop and face reality.
Whoever modded you insightful should have chosen Funny instead.
Re: (Score:3, Insightful)
Re: (Score:2)
Remind me not to hire you. (Never mind, I'll remember.)
Re: (Score:2, Insightful)
Remind me not to work for you.
Re: (Score:1)
Re:O'Reilly's PHP cookbok preferable (Score:4, Insightful)
I don't think you'll need to. You seriously think writing off 1 in 4 visitors to your site is acceptable business sense? Even in your contrived example of selling Firefox manuals, you'd be driving away business as (a) you'd get people interested in Firefox who are currently using IE at home or browsing from an Internet Café or library or University or work and (b) people such as myself who would think to themselves - if the guy finds it so difficult to make some changes for compatibility then why would I want to read a technical manual from him? And this is ignoring that your Firefox Manual selling site is hardly what you'll be asked to do in the real world as a web designer.
Re: (Score:2)
Well, I've done that intentionally, and been happy with the results.
You've gotta consider that some "businesses" don't want to maximise their visitor count; they want to maximise the number of visitors who want something that the site provides.
The example I'm thinking of is a site that I manage that provides several useful services to musicians. It also
Re: (Score:2)
That's an interesting example of wishing to filter the visitors to your site. I fully agree with your logic... though it's backfired in this one instance as you've just had a curious Slashdotter wander in their via your Homepage link.
It's very different to the poster I was replying to however, who was trying to make the case that they wished to filter out IE6 users as a business model. That was hard to justify even in the weird example they gave and it was clearly a mask for either not wishing to take
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re:O'Reilly's PHP cookbok preferable (Score:5, Insightful)
I agree. I design in Firefox, then test in IE7, Safari, and Opera, and finally make sure it isn't too broken in IE6. In fact, if it isn't broken enough in IE6, I'll use some hacks to make it a little more broken, along with prominent dire warnings about how they are using a broken browser that can't support the "advanced features" of my site and they need to upgrade.
Petty and immature? Yeah, probably. But IE6 made my life a living hell for plenty of years and now that it's no longer the dominant browser it makes me feel better to turn some of that pain right back around. If I can get just a small percentage of those 25% users to switch to a better browser, then I will have made the internet a bit better for everyone and that's definitely worth the lost customers I may have caused.
Re: (Score:2)
If you worked in a store would you tell 1 out of 4 customers to go to hell because its cheaper to have less cashiers and clerks?
IE6 will become irrevelent hopefully when it reaches below %10 marketshare but still that is huge too to ignore. Vista is not helping people want to upgrade either.
Re: (Score:1)
Re: (Score:1)
So you see? there is a purpose for malware: they encourage system updates that keeps everyone somewhat on the same page.
Now developers could continue moving forward with the latest and greatest.
Re: (Score:1)
Re:O'Reilly's PHP cookbok preferable (Score:4, Interesting)
Any web developer worth employing knows about browser deficiencies, and will effortlessly code around them using various sniffs, hacks and conditional comments. Giving a significant proportion of visitors a degraded experience just isn't on - coding for one browser is lazy, and choosing, say, Firefox as a preferred platform is no better than choosing Internet Explorer. (Remember IE-only websites?)
Idealistic? Hardly - you may find that the Person Who Pays The Bills is running IE 6...
Re: (Score:1)
Re: (Score:2)
Ha-ha-ha
IE5/IE6 support added about 50% (sometimes more!) to projects I did in the past. Maybe I'm not worth employing but IE6 doesn't generally get a look in now (too much cost to bother with, just basic support, no gloss) - most of the sites I work on however are community groups / charities.
I can't imagine any web designer / developer saying that coding round IE6 was effor
Re: (Score:2)
In terms of laziness, aren't you pointing at the wrong people? Choosing to code to standards should be the preferred method. Not implementing standards in your browser is lazy (or worse).
Re: (Score:1)
(That's why we have all those funky Flash sites with do-superb-special-effects-on-everything-especially-on-menus(tm) where you have to wait minutes, and I'm not counting loading time, to get to the information you really need.)
Re: (Score:1)
Me, I just try my best to support both. I don't see IE6 as the enemy, even though it does create stress... my enemy is Opera/Safari/Konq and all the other one-off niche browsers. For those small players, my rule is "best effort
Re: (Score:1)
Re: (Score:1)
Umm, GIFs by definition are 8-bit, so it's not "almost." You mean GIF 89a's indexed transparency support, which IE also supports with PNGs.
Considering PNGs yield smaller compression ratios universally in 8-bit (indexed, with support for the indexed transparency) compared to GIF, there's really no reason to use the obsolete format anymore, except for browsers from the early-mid 90's. Heck, even Netscape Navigator 4.0 supports PNG rendering, so the "old browser" argument isn't really useful anymore.
Re: (Score:1)
Forget PHP, use Python (Score:1, Interesting)
PHP6? (Score:2, Insightful)
Re:PHP6? (Score:4, Informative)
Re: (Score:2)
Huh.
My apologies - apparently, my due diligence was not due enough.
Thanks!
Re:PHP6? (Score:5, Insightful)
Besides, if these books are really for professionals, shouldn't they be able to adapt the solutions to php6 rather easily?
Re: (Score:2)
Re: (Score:2)
like the others? (Score:1)
marketing 101 (Score:5, Funny)
then
author && editor == dumb fuck
endif
Re: (Score:1)
those are comparissons.
$author = $editor = 'dumb fuck'
php syntaxnazi
Re: (Score:2)
title (Score:2, Funny)
cook book & ideas (Score:1)
Story time:
Not to give a random plug or anything, but a while back I read a PHP cookbook (2006ish) and it had a small section on a plugin called "Ming" which can generate flash animations without using proprietary tools. I took what little was available on the web and (for the past 2 years) have been developing http://www.icanimate.com/ [icanimate.com] which allows users to generate animations(in a java applet) which can be played back in a flash animation(through PH
Re: (Score:2)
I've read large chunks of the "PHP Cookbook" and it's not bad. There's useful information in there, though the tome is a little indigestible. The absolute best book I've read of this kind is the Python Cookbook. Admittedly, I was still learning Python at the time and so I was enjoying all the little discoveries about the language, but it's a seriously good book and in an age of convenient online references and tutorials, is maybe one of the few programming books that is absolutely worth buying. Absolutely
You shouldn't need a "cookbook". (Score:4, Insightful)
If you actually understand the language that you're using and the basics of programming, you should be able to handle most simple cookbook-type programming problems without any help.
Now, sitting down and reading one of these "cookbooks" (straight through, like a novel) when you're learning a new language might be a good idea; it helps get an idea of the programming style used in the community around the language. But, if you find yourself constantly using one of these things as a reference book for solutions then you should take that as a sign that you should probably go pick up a "Learning Language X" book and actually read it.
Programming patterns = very good "cookbooks" (Score:3, Interesting)
Re: (Score:1)
Re: (Score:1)
Reviewing the review (Score:2, Interesting)
Say what?!
They are language constructs, not functions (so your notation is kinda wrong, otherwise valid point).
Their PHP was compiled with libmcrypt version 2.2.
Re: (Score:2, Informative)
This slows down the PHP interpreter by forcing it to check for variables within the strings, to be interpolated.
Say what?!
Say what, what? Using "" strings which support interpolation is slower than using '' strings which don't (even accounting for the dot operator concatenation of the variables to the '' string). Often "" is preferable anyway for code readability and with the inherent latency of the web for which PHP is most often used it's like a drop in the ocean, but still, any benchmark of PHP will support the fact that "" is undoubtedly quite a bit slower than ''.
Re: (Score:2)
However, I think (hope) the confusion may have been in the word "interpolated", which should have been 'interpreted', 'substituted', 'replaced', or any number of other words.
Re: (Score:1)
"Interpolated" is actually correct.
Re: (Score:2)
Well the latency of the web isn't so much the problem as the scalability of the script. An extra 50ms means nothing to the end user, but if you're getting twenty page views a second, you're going to find your server getting back-logged really quickly.
However, I think (hope) the confusion may have been in the word "interpolated", which should have been 'interpreted', 'substituted', 'replaced', or any number of other words.
"50ms" is a made up number. Show me where a real world profiler (on a realistic php script) has shown interpolation to be a major bottleneck. Don't optimize prematurely - there are almost always far bigger problems to deal with than variable interpolation.
And yes, "interpolation" is the exact correct word in this context.
Re: (Score:2)
Re: (Score:1)
Re: (Score:1)
If that's actually true to any substantive degree (network latency is likely your biggest bottleneck when talking about HTML generated by PHP), there's something very wrong in the PHP core. The right way to parse code into some sort of AST or optree means that the parser emits a different tree for a double-quoted string with no interpolation than for a double-quoted string with interpolation. That tree sho
Re: (Score:1)
You're right. That's there's something very wrong.
"quoted text with $var" is converted to 'quoted' . ' ' . 'text' . ' ' . 'with' . ' ' . $var.
I prefer the PHP Phrasebook (Score:1)
Re: (Score:1)
all too common problem (Score:4, Insightful)
Did no one test the sample code before publication?!
This is one of those things that I just can't understand. I ran into this same thing when trying to get up to speed on C++ on Windows a few years back. I picked up a copy of Visual C++ .NET Bible (only to find out it had almost nothing to do with .NET) and found it's examples were completely bug ridden. I found one example that had something like 20 bugs in it.
One would think on the web where fast publication generally happens you might see this. But in an introductory text, where examples will cause profound confusion, you would think they could at least do a single editorial debug pass through it. More so, it's a freaking dead-tree book, if you are going to publish something that will last for years, and it has your name on the cover, try checking the examples!
BTW, for those who think O'reilly is immune to this, it's not - I have a number of O'reilly texts I bought based on their rep only to find out they published a useless doorstop.
Re: (Score:1)
Well, hopefully it was less maddening than my class in Unix/C, where I enjoyed the insanity of a (nearly) 40-year-old operating system/language, coupled with the insanity of many typos.
Re: (Score:2)
Did no one test the sample code before publication?!
This is one of those things that I just can't understand. I ran into this same thing when trying to get up to speed on C++ on Windows a few years back. I picked up a copy of Visual C++ .NET Bible (only to find out it had almost nothing to do with .NET) and found it's examples were completely bug ridden. I found one example that had something like 20 bugs in it.
One would think on the web where fast publication generally happens you might see this. But in an introductory text, where examples will cause profound confusion, you would think they could at least do a single editorial debug pass through it. More so, it's a freaking dead-tree book, if you are going to publish something that will last for years, and it has your name on the cover, try checking the examples!
BTW, for those who think O'reilly is immune to this, it's not - I have a number of O'reilly texts I bought based on their rep only to find out they published a useless doorstop.
The things this reviewer complained about the most seemed to me to depend on environmental settings and would be very server specific. He complained about short tags (there are many scripts that rely on short tags, good bad or ugly)when short tags can be set in the server configuration. And complaining about the difference in quoting styles and the difference between print and echo? The review lost any sense of objectivity when he started picking nits.
Re: (Score:1)
Sometimes I wonder. Maybe since I had the luxury of self-publishing I could make sure it was right, but if it isn't right, why bother publishing it!
Is this necessary? (Score:1)
Warnings != errors (Score:2)
Both of those are Warnings, not Errors. And in true PHP tradition, unless it breaks the script completely (which Warnings don't by default), it's not only not wrong, but pretty close to best practices.
Honestly, this sounds like one of those books that gives PHP its bad reputation.
Re: (Score:2)
I code in PHP regularly and I don't even let notices slip by without correction. Yes, PHP lets any garbage code run, yes that's not a good thing; but that's why PHP is so popular, cause it's so damn easy to make a script.
PHP trolls (I'm not accusing you of being one) never seem to get that.
Re: (Score:2)
I actually like working in PHP, and I know the fact truly horrible code can run fine on it is one of the reasons it's so popular, but people who write these sorts of books should really know better than to think the fact that their crap code runs makes it fine to hold up as an example to students.
Re: (Score:2)
echo "$string";
So... (Score:1)
The 80s called ... (Score:5, Insightful)
... they want their slang back. "Wicked cool"? Seriously? While it's entirely possible that this phrase has made a comeback of which I am unaware, I would think using the word "wicked" totally cancels out (or possibly negates) the word "cool". Why not name it "Totally far out PHP"? "Really swell PHP"? From a marketing POV, the slang used in the title of a programming language book should probably not pre-date the programming language itself.
Just my opinion. I'm not an author or a marketer.
Re: (Score:2)
I'm a transplant to New England, and hear "wicked" used with some frequency. They also say "cool beans." Sometimes I even hear "Wicked cool beans." I think they say that just to be "pissahs."
Re: (Score:2)
Oh, I didn't know it was a regional expression. Come to think of it, last time I was in New England was ... in the 80s. It's interesting that I got modded "+5 insightful" for an apparently unjustified criticism. Such is karma, I guess.
Re: (Score:2)
Re: (Score:1)
Re: (Score:2)
So my upcoming title "Awesomely Rad FORTRAN" is still ok?
Re: (Score:2)
Re: (Score:1)
It should have been "Wicked Pissah PHP"
Re: (Score:2)
But that would only leave OMG PHP LOL!!!11 as a possible title.
Hmm... actually,
looks kinda cool. :-) Reminds me of an idea I had for a PHP site:
It even works as a cheer: "Angle bracket, question mark, P H P..."
"Professional work" (Score:4, Insightful)
You picked up "Wicked Cool PHP" and expected a really stodgy, professional work?
cross-site scripting? (Score:3, Funny)
No book on php could miss examples of how to do this, surely? Its the number one thing that php programmers need to be able to do! Apparently...
Professional or Hip? (Score:2)
From the review seeing "require_once" as the solution to including files shows that code organization is apparently not being taught. It's the "goto" of PHP. Instead of laying out the code in a clean logical fashion that avoids redundant includes you can simply use "re
Re: (Score:2)
From the review seeing "require_once" as the solution to including files shows that code organization is apparently not being taught. It's the "goto" of PHP. Instead of laying out the code in a clean logical fashion that avoids redundant includes you can simply use "require_once" and avoid that whole process.
It's not always that easy, and the test is simple. It's probably not worth the time to sort out.
/* ... code ... */
PHP isn't the only place this metaphor is used, many C headers have something like:
#ifndef DATA_H
#endif
hella awesome gnarly php dude (Score:2, Funny)
-fragbait
Re: (Score:2)
php limitations (Score:2, Insightful)
For instance, in section #30, validate_cc_number defines a variable as $false = false, but this "variable" never gets changed in the rest of the script. That is what constants are for.
It doesn't sound like it in this case, but if a function returns a value by reference, you would need to put a constant in a variable before returning it.
Just Terrible (Score:2)
Use classes. Take advantage of libraries like HTML_QuickForm or Zend_Form. If those don't meet your needs, build your own. In either case, learn about the common securi
Re: (Score:2)
And indeed the book does - that chapter is chock-full of HTML injection holes, leading to cross-site-scripting vulnerabilities. After giving the standard "Very important is a security!" spiel at the beginning this is a bit disappointing.
PHP as a language may have made some poor design choices, but the main reason so many PHP coders are security-ignorant - and consequently so many PHP applications are plagued with endless security
Writers / Editors Not Reviewers (Score:2)
Overall I think the review had a few good points, but started devling into a one-upmanship type sitation. It became obvious to me that there was a virtual axe to grind and it was not a suprise to see the reviewer claims to be a writer and editor.
Somewhere it stopped being about real flaws, and became a game of pointing out minutia
Inadvertant advertising campaign? (Score:1)
The FAQs of Life (Score:2)
Re: (Score:3, Insightful)
I use PHP all the time. It can be used well, though it has been abused terribly by the masses. But cool? I think it lost its coolness quite some time ago.
The reviewer also nitpicks about the use of single quotes vs double qoutes, as double quotes have to interpolate variables etc... Come on, most code out there has bigger performance problems to deal with. Variable interpolation is not that bad.
I keep finding blogger wh
Re:Shouldn't it be just "Wicked PHP?" (Score:5, Insightful)
Re: (Score:3, Insightful)
Re: (Score:2)
Not really; it just happened to be in the right place at the right time. ASP (not ASP.NET yet) sucked even more, and JSP was much more complicated, and ColdFusion was not free. And, of course, the fact that you could get an Apache+PHP+MySQL all-in-one bundle as a Win32 installer helped a lot (there wasn't any official bundles, but there were plenty of third-party ones which worked great in practice, especially so when they were put on a CD accompa
Re: (Score:2)
(Don't get me wrong, I don't hate Perl
Re: (Score:3, Insightful)
Because many of the inconsistencies are minor (who cares if it's noun_verb, nounverb, or verb_noun? str_split, stripclashes, strip_tags... BFD!) and who cares about limits if you don't bump your head against them? Not everyone needs to write computer-science-textbook-worthy apps or bulletproof-scalable-enterprise-ready apps day in and day out. A shared phone book or simple inventory sys
Re: (Score:2)
That's a dangerous outlook. The "right" way is the right way for a reason, and PHP makes it very easy to get it terribly wrong. SQL injection attacks, cross-site scripting vulnerabilities, intimate tying of HTML to code, and non-existent internationalization are all the default for PHP. You may not think these things matter for your quick and dirty application, but programs are often used for far more than they were ori
Re: (Score:2)
These aren't arcane "computer-science" concepts. They're real world limitations that make it hard to write good software in PHP. Other languages, like Perl, Python, and Ruby force you to think about the inherent problems in web development
If this would be true these languages won't have the same problems like XSS or SQL injections. The stupid PHP developer would be just as stupid in any other language.
instead of embedding variables in SQL statements, use a query builder. Instead of mixing HTML and code, use a template library. Instead of using $GET indescribably, structure your code so data only flow where they're needed.
http://php.net/pdo [php.net] (I don't like hiding SQL just because, that's why I use prepared statements instead of a query builder)
http://smarty.php.net/ [php.net] or just PHP, which is a template language (if you know how to separate)
http://php.net/filter [php.net]
It's not like the language forces you to do all the evil things. Many of the problems have been solved and
Re: (Score:2)
PHP is "quick, cheap and easy" only in a sense that it's how it was written itself; it was not designed to allow you to write code in it "quick, cheap and easy" (one could argue, looking at the mess that it is, that it was hardly designed at all). It's just a tool that a million of web coder monkeys eventually settled on because it was there, and it was free, and so now its main strength is that you can find PHP/MySQL developers a dime a dozen. Th
Re: (Score:1)
Re: (Score:2)