Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
×
PHP Books Media Programming Book Reviews

PHP Cookbook 238

CEHT writes "Like Tony Williams said in his review on PHP and MySQL Web Development: "PHP and MySQL are probably the most pervasive add-ons to Apache web servers across the web". And I agree with him. PHP is a very powerful scripting language, so developers (not just web developers) can do almost anything with it." Read on to see how well CEHT thinks O'Reilly's PHP Cookbook helps you do that almost everything.
PHP Cookbook
author David Sklar and Adam Trachtenberg
pages 608
publisher O'Reilly
rating 9
reviewer Edmond Lau
ISBN 1565926811
summary Solutions and examples for PHP programmers.

The approach that the authors use in PHP Cookbook is great. Like most computer books, the authors usually include a summary (in sentence forms) to illustrate what the readers will expect in each chapter. Skalar and Trachtenberg take this even further by including some preliminary (code) examples to explain the general ideas behind each chapters. The examples in the book are self-contained. In most cases, I've found examples to exactly fit my needs -- this makes it one of the better reference books.

Each chapter in the book is divided into multiple sections of Problem / Solution / Discussion with a FAQ style. In each case, a simple description of a problem is followed by a PHP script as the solution. But the meat is actually in the discussions: in-depth details are included here, where the authors also include references, extended ideas, and scripts to inform the readers how much more they can do about the issue.

For example, I was going to add a simple script to my website to parse RSS/RDF files from certain news websites (CNN, Slashdot, ...), and use it as my Mozilla homepage. (Who wouldn't?) This script seems to be simple, but I may make a mistake here and there. As reference, I opened up the book to the section "Parsing XML with SAX." Then I realized the authors already had the script to parse RSS/RDF files in the discussion. Bravo!

For myself, the most useful chapters I found are: Web Basics, Forms, Database Access, and XML. There are also good examples in topics such as security, internationalization, and file processing/management. However, this book does not cover the basics of PHP. If you are a good programmer, you should be able to get away with this using the PHP Manual. A good book to learn PHP is Programming PHP, also by O'Reilly.

Although this book covers a wide range of topics, it does not cover topics like generating PDFs. I would also like to see the authors add one (maybe two) case studies in later editions. That would give the reader a more concrete example of how to combine tricks presented by this book. Other than that, at the price of $39.95 (or $61.95 CAD), this book is a great buy!

Topics

  1. Strings
  2. Numbers
  3. Dates and Times
  4. Arrays
  5. Variables
  6. Functions
  7. Classes and Objects
  8. Web Basics - available online as example chapter
  9. Forms
  10. Database Access
  11. Web Automation
  12. XML
  13. Regular Expressions
  14. Encryption and Security
  15. Graphics
  16. Internationalization and Localization
  17. Internet Services
  18. Files
  19. Directories
  20. Client-Side PHP
  21. PEAR


You can purchase the PHP Cookbook from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

This discussion has been archived. No new comments can be posted.

PHP Cookbook

Comments Filter:
  • PHP Security (Score:5, Interesting)

    by leeroybrown ( 624767 ) on Monday June 09, 2003 @12:05PM (#6151126)

    One thing I would like to see more PHP books do is to cover the various Security problems that are prevalent in many PHP based web applications.

    Don't get me wrong, I find PHP to be the best and friendliest solution for many things, but some of the Security problems could easily be avoided with some common sense security advice.

    • Re:PHP Security (Score:4, Interesting)

      by Albert Pussyjuice ( 675113 ) on Monday June 09, 2003 @12:24PM (#6151330) Homepage Journal
      You are right - there is a general lack of books which deal with writing very fault tolerant and secure PHP code. Most of the PHP books I've seen in the stores start from the basics and focus on getting a database connection up and running and then doing some simple input/output/db access. I think that while PHP has taken off as a web language, this has hindered development a bit because everyone using PHP keeps running into the same problems and has to recode constantly to work around them.

      Of course, writing secure code isn't specific to a language and any book on writing secure code should help to pave the way to avoid common mistakes, just substitute PHP for language X. For instance Writing Secure Code [amazon.com] by Michael Howard could be a good companion book to any programmer's library.

      Hopefully, in a few years PHP will have a large enough installed user base (as I think it already does) that the advances issues such as security, tolerance, etc. will be dealt with in entire book(s). Can you tell I am a PHP afficianado?

    • Re:PHP Security (Score:5, Insightful)

      by cyt0plas ( 629631 ) on Monday June 09, 2003 @12:25PM (#6151340) Journal
      The security problems usually aren't the problems of php, it's the developer's problems. PHP is one of the most newbie friendly web development languages out there. For heaven's sake, it even escapes user inputted strings FOR YOU. That stops most sql exploits, shell string exploits at the door. What happens is that some newbie who hasn't taken the time to read the documentation does something dumb like include($_GET['filename']); While this is a exploitable situation, how many CGIs have been exploited because the author failed to strip/escape user input?

      PHP has a couple of common mistakes, but I'm far more apt to trust an inexperienced PHP programmer over an inexperienced Perl programmer, as far as secure code goes.
    • One thing I would like to see more PHP books do is to cover the various Security problems that are prevalent in many PHP based web applications.

      I completely agree with you. David Sklar (one of the authors of the book reviewed here) gave a very interesting presentation about the subject of security in web applications at the International PHP Conference (May 2003) in Amsterdam. You can view the slides of his talk here [php.net].

      JP

    • Re:PHP Security (Score:3, Informative)

      by ikewillis ( 586793 )
      I'm working on a project that aims to solve the matter of keeping database access passwords secure when using PHP as an Apache module (and consequently all PHP scripts must be readable by a single user)

      It's called phpkeychain [sourceforge.net] and it's modelled after the keychain mechanism in OS X.

    • 'web apps' (Score:3, Insightful)

      by Kunta Kinte ( 323399 )

      One thing I would like to see more PHP books do is to cover the various Security problems that are prevalent in many PHP based web applications.

      I think a large part of the problem is that PHP is illsuited for many of the larger web applications it is being used for. Traditional Application Server features such as tag libraries found in JSP, ColdFusion, etc. would be good for separating the 'coders' from the 'presentation designers' in large projects, but that's not pertinent to security.

      What gets l

      • The end result is heavy dependence on databases for variable persistance and error-prone algorithm concoctions, a la PHPNuke et. al.

        Yes, but PHP has sessions. At my work, we use the session features to do variable persistance. What am I missing? I'm sure I've failed to grasp the crux of your argument.


    • some of the worst problems e.g. register globals on as the default setting has disappeared in the latest versions, but I generally agree.
      I have this book, and it has got some good examples I have been able to adapt and use, but it does need a good understanding of PHP, SQL and HTML to get the most out of it.

      If you want a starter/ reference book, wait a few weeks until PHP5 comes out, and I will be spending my dollars on Leon Atkinson's latest edition in the Core series.
  • YES!!! (Score:5, Funny)

    by SuperDuG ( 134989 ) <<kt.celce> <ta> <eb>> on Monday June 09, 2003 @12:06PM (#6151129) Homepage Journal
    Please continue to make these books, I would love to "quit passing on my knowledge" to the morons around me!!

    In all seriousness I enjoy PHP because it is pretty self explanatory, and it can use plain old html inside it too. It's just nice to use a scripting language for the web that was made for webpages originally, not a language that was created for ...

    ... does anyone really know the original intent of perl? I guess that's like trying to find the oringal intent for ducK tape (and no, don't say to seal off ventilation ducts, coz that's what they'd have you believe.)?

    • Re:YES!!! (Score:3, Funny)

      by maharg ( 182366 )
      Practical Extraction and Report Language

      OR

      Pathologically Electic Rubbish Lister
    • Re:YES!!! (Score:5, Informative)

      by Surak ( 18578 ) * <surak&mailblocks,com> on Monday June 09, 2003 @12:20PM (#6151296) Homepage Journal
      ... does anyone really know the original intent of perl? I guess that's like trying to find the oringal intent for ducK tape (and no, don't say to seal off ventilation ducts, coz that's what they'd have you believe.)?

      Duck tape was invented during WWII by Johnson+Johnson for the purpose keeping water out of ammunition cases -- it was relatively waterproof, hence the reason people in the military started calling it "duck tape."

      You should try watching the History Channel more often. ;)

      • Okay I really wasn't expecting a correct answer there. I don't know which is worse, the fact I knew that ... or the fact someone other than me watches the history channel that much.
    • ... does anyone really know the original intent of perl?

      To manipulate text. Funny since everything is going to a text/XML type of meta format Perl is very well suited to the Web and to system management or for small GUI programs. I think Perl would be a great replacement for say VB.

      *Obligatory PHP flame from the Perl guy*
      of course Perl can do all that and it doesn't need_a_function_for_everything() to accomplish it either.
      */Obligatory PHP flame from the Perl guy*
      • Re:YES!!! (Score:3, Funny)

        by Photon Ghoul ( 14932 )
        of course Perl can do all that and it doesn't need_a_function_for_everything() to accomplish it either

        No, it just needs a module_for_everything.pm :)
    • Perl has its roots as a tool combining the virtues of sed and awk, and was started mainly as a text parsing/processing language. This is one of the many reasons why it is so good as a web development language.

      What seems to scare people about perl is that there as so many different ways that you can tackle a job like building dynamic web sites. Perl on it's own doesn't forcefeed anything to you, it lets you find your own style. Many people who start with perl will try to do everything from scratch instea
    • I thought perl was originally for advanced text processing... I can't imagine trying to write half the basic admin/dogsbody scripts I knock together, for general system maintenance or one-off conversions, with only sh, sed and awk. (Of course, the other half I *did* write with sh, sed and awk, just to keep up the chest-hair/real-man quota :) )

      Anyway, because the brunt of most simple CGI applications is text processing, perl got moved into being used for that.
    • Perl fast facts [perl.org]

      Perl stansds for "Practical Extraction and Reporting Language". Invented in 1987 by Larry Wall, it was originally used for in system maintenance tools for UNIX, mostly parsing logs and foramatting the results for display on the screen.
  • by bloxnet ( 637785 ) on Monday June 09, 2003 @12:07PM (#6151139)
    Not to be confused with "PHP Developer's Cookbook" (ISBN: 0672323257 - Publisher: Pearson Education) which is a very well regarded reference for PHP. Just wanted to avoid confusion and suggest the book at the same time. There seems to be a flood of PHP/MySQL books out there, or people are just getting around to reviewing them....not sure.
    • There seems to be a flood of PHP/MySQL books out there

      Most of books are for most of peoples. The smarter the subject the fewer people can understand and demand it.

      That's why you see most of books about VB, ASP, JSP, PHP. Less about Perl/CGI. Even less about Python/CGI. Just 2 good (totally 4 found) books about Zope. No books (at least in several stores I've checked) about web-programing with Lisp, Scheme, OCaml or Haskell.

      Well, in the past the reading the hard-printed books was a sign of smart/educate

  • As a web developer, php has been a real life saver.

    It would take a whole lot of perl code to achieve the same functionality that can be accomplished in 200 well-written php code. (Depending on what it did - it's based off my personal experiences).

    In addition, the ability to mix and match html/php on a cross-platform programming language, as well as write scripts that also run on the command line is worth it's weight in gold (note to people who don't understand that saying, it's really valuable to me).
    • It would take a whole lot of perl code to achieve the same functionality that can be accomplished in 200 well-written php code.

      You obviously don't know Perl, at the very least you don't know about CPAN. How about a decent HTML parser for PHP. XML? How about this: write a program that reads an Excel spreadsheet and uploads its content into a database and let me know how long it takes you in PHP.

      PHP sucks because there is no standard way to extend it, and don't mention PEAR as it so poorly documented its a
      • The one advantage I see to PHP over Perl is persistant session management. To recreate that in perl is quite a bit of work. Even then, in CGI environments it's not a true session, but one that gets reconstructed from files or a database with every page request. At least, that's been my experience. It's very possible that perl has something for that (there's lots of third party modules), but I haven't found it yet.

        For general web stuff, I normally choose PHP because of it's ease of use in most situations. F
    • Re:Ain't php great? (Score:4, Informative)

      by Mr Bill ( 21249 ) on Monday June 09, 2003 @12:45PM (#6151526)
      It would take a whole lot of perl code to achieve the same functionality that can be accomplished in 200 well-written php code. (Depending on what it did - it's based off my personal experiences).

      If that is a challenge, then I accept. I can guarantee you that for every command in PHP, there is an equivalent command (or module) in Perl. Hence you should be able to write this imaginary program in exactly the same number of lines...

      Although perl and cgi scripts can be ran from the command line, they can't have (X)HTML mixed in quite as easily.

      Have a look at Embperl, HTML::Mason, Apache::ASP for a couple of examples of how to do this. Most people who knock perl have never discovered the right tools. Personally I would never use those tools, because I am a strong believer in the separation of Code and HTML. I use a templating system for all my projects, and you will never see one HTML tag in my code. Once you work with a team of developers and a separate team of designers you will understand the need for this separation.

      PHP is a great tool! I have used it for several applications in the past (6 or 7 years ago). But if you think that PHP can do more than perl can then you are mistaken...

      • I can guarantee you that for every command in PHP, there is an equivalent command (or module) in Perl.

        Well, it'll be a module, not a built-in; Perl's built-ins are often powerful in the broad thermonuclear sense, but are never web-specific. Two key differences remain, though.

        One: The Perl modules will have 15 dependencies each, 3 of which are no longer available at CPAN and which have to be hunted down from a Taiwanese mirror using archive.org.

        Two: The various Perl modules you need will use differe

    • I've never understood what the attraction of php over perl is, maybe someone could explain. When I look at the two of them it looks like for simple pages they are about equal: peanut butter in chocolate verus chocolate in peanut butter.

      For example,
      php embeds code-like active statements in between static html. where as perl embeds HTML text in between perl commands. Each of them requires designated separators to keep the text and commands separated.

      to be a little more specific, since perl had HERE stat

  • by leeroybrown ( 624767 ) on Monday June 09, 2003 @12:11PM (#6151192)

    I've been doing PHP web development on and off for a couple of years now and I've always found that it's greatest strength has been the availability of very god online resources.

    PHP.net [php.net] and many other excellent resources are only a browser click away and remain up to date for free. PHP is one of those areas where I'll save my money and buy a book I'll get genuine reference use from.

    • Nothing like having half a dozen browser windows/tabs open at the same time, trying to fix/write your web page app. Give me a book any time, realspace makes it a lot more convenient to arrange references around me, IMNSHO. That said, I do appreciate the web references, they're good backfill when nothing else seems to solve the problem. Most of the time. Sometimes googling for answers is like finding a needle in a haystack.
    • The only trouble I see with the web site and any of these books is that there's never any discussion of "best practices".

      Just because I can easily find a way to do X on the php.net site (which is admittedly where I've learned shitloads), doesn't mean the methods found are any good...
  • I've got the Perl cookbook, and have used many of the source code samples found inside in my work. However, most of the development I do is PHP, and I'm extremely excited to hear that they've released a cookbook for PHP. I reccomend this and the Perl cookbook to any developer who wants advice or inspiration.
  • by Anonymous Coward on Monday June 09, 2003 @12:18PM (#6151274)
    1) consistant database integration - Why not have a SetDBType() function, rather than hardcoding mysql_connect, mssql_connect, myodbc_connect, pgqsl_connect, etc?

    2) Native XML support - It's just not there? Why re-invent the wheel each time? Give us a good XML tree-walking engine DAMMIT!

    3) sane and consistant functions. Single quotes, double quotes, some functions work with both, some work with one or the other, embedded html in an echo screws up if you don't double quote it, etc.

    4) .NET support?

    In short, PHP is a good language for small projects, but just doesn't cut it in an enterprise setting.
    • The PEAR packages, usually bundled with the distribution, would take care of the first two:
      http://pear.php.net/

    • by weston ( 16146 ) <westonsd@@@canncentral...org> on Monday June 09, 2003 @12:40PM (#6151479) Homepage
      1) consistant database integration - Why not have a SetDBType() function, rather than hardcoding mysql_connect, mssql_connect, myodbc_connect, pgqsl_connect, etc?

      I believe there is a PEAR package [php.net] that abstracts an OO layer over the functions to various databases. Think DBI for PHP.

      2) Native XML support - It's just not there? Why re-invent the wheel each time? Give us a good XML tree-walking engine DAMMIT!

      Natvie XML support is there. A SAX parser is usually built in by default. I'm happily using a DOM XML interface that I compiled into my version.

      3) sane and consistant functions. Single quotes, double quotes, some functions work with both, some work with one or the other, embedded html in an echo screws up if you don't double quote it, etc.

      Quotes in PHP do work in a sane and consistent way, very similar to the way they work in PERL. The only thing I mourn is the lack of a qq[-like facility (and I wouldn't be surprised if someone snuck it in while I wasn't looking, and I just didn't know about it).

      4) .NET support?

      Um.... why?
      • Quotes in PHP do work in a sane and consistent way, very similar to the way they work in PERL. The only thing I mourn is the lack of a qq[-like facility (and I wouldn't be surprised if someone snuck it in while I wasn't looking, and I just didn't know about it).

        Not yet, AFAIK, but you can always use the heredoc [php.net] syntax to achieve the same effect -- the only problem is that the heredoc terminators kind of disturb your indentation. Still very useful for large string literals....

    • I'm pretty sure this is a troll (I mean, .NET support?), but since it's had a large amount of "Insightful" mods, I figured I would point out at least one misconception.

      The parent poster complains about "consistant (sp) database integration" as one of the main problems with PHP. This is usually a problem noted only by those who haven't used PHP in serious development. Sure, if you're writing a 20-line script that you know is only going to use MySQL, then who cares what database connection statements you're
    • PHP 5 will have much much better XML support.

      There is a lot of work on a complete new DOM extension, which should clean up the mess done in domxml as of PHP 4. It will follow the W3C DOM API as much as possible and is completely rewritten from scratch.

      Furthermore Sterling Hughes is working on SimpleXml [edwardbear.org]. An extension which should make it much easier to access XML Documents with the usual PHP functions.

      The SAX Parser in PHP 5 will also be based on libxml2 and not anymore on the aging expat library.

      XML Val
    • 1) consistant database integration - Why not have a SetDBType() function, rather than hardcoding mysql_connect, mssql_connect, myodbc_connect, pgqsl_connect, etc?

      Try ADOdb [weblogs.com]. It is a database access library for PHP which seems to work well.


    • 1) consistant database integration - Why not have a SetDBType() function, rather than hardcoding mysql_connect, mssql_connect, myodbc_connect, pgqsl_connect, etc?

      Because different databases do different things, and abstracting degrades performance -- you CAN, however use ODBC with PHP. I do abstract whenever time allows. Manual abstraction is easy. There's a DB:: class in PEAR [php.net] as well as ADOdb [weblogs.com].


      2) Native XML support - It's just not there? Why re-invent the wheel each time? Give us a good XML tree-walki
  • <rant>
    I'm a PHP/MySQL junkie, and every time I see anything about PHP on /. its a damn book review. I know the dynamic duo (php/mysql) are the hottest things to hit the net since <blink> but could we get some more interesting new on php, how about something on php-gtk, or the various other php related projects.
    </rant>
  • Good learning tool (Score:2, Insightful)

    by mni12 ( 451821 )
    I actually bought a copy of this book, as well as the other one referenced in this review. I found them quite useful in learning PHP - the examples can be easily tweaked to create useful little applications. I haven't done very much with web programming except for few CGI-scripts and PHP definitely looks much easier way to create useful applications.

    The examples of integrating to MySQL were especially useful as I have been playing with Microsoft Access using MySQL as server, and now I can easily create web
  • What I want to know is if there's any way to do any sort of Reflection in PHP. I'd buy this book if it had anything on that subject. JSP, ASP.net, and ASP all have Reflection or at least some features similar to it, but PHP seems to have nothing of the type... and there are some types of code that are next to impossible to write without Reflection - things like XML serialization/deserialization in particular are a pain without it.
  • by jpkunst ( 612360 ) on Monday June 09, 2003 @12:25PM (#6151339)

    ... is (IMHO) the MySQL Cookbook [oreilly.com]. The 'Cookbook'-format (specific real-world problems and possible solutions) makes for extremely useful books.

    JP

  • This book has been out for nearly a year. Is this news?
  • by Naum ( 166466 ) on Monday June 09, 2003 @12:41PM (#6151488) Homepage Journal
    ...PHP developer.

    Relevant, real-life useful examples are given and even a seasoned pro like me picked up a few gems like the example user authentication code that utilizes a hash instead of having to go back to the database on each page fetch.

    My bookshelves are full of PHP books but most of them are inferior to the online documentation at php.net. They add nothing and are a true waste of trees. This one, however, does not fall into that category.

  • I'd give anything (Score:3, Insightful)

    by digidave ( 259925 ) on Monday June 09, 2003 @12:56PM (#6151641)
    to see a book that deals with advanced application design in PHP. The problem with PHP is that most PHP developers are amateurs who don't know the first thing about app design. At best, apps are written with objects used randomly to accomplish some tasks and mostly include files for 2 dozen reused functions (or functions that aren't even reused, but still included in every page).

    At worst, every database connection is hard-coded in a different place and there are no comments anywhere.

    In either case, my God help anyone who wants to add functionality. These same people need a good book on relational database design, or be subjected to 4 years of universigy RDBMS design courses like I was. IMO, if you aren't willing to slit your wrists to get out of an RDBMS design class, you haven't taken enough of them.
  • I expected somebody to come in and say, "PHP's object support is not very good and OO and GOF patterns are the savior of code management and mega-reuse and getting dates, etc. etc." But I have not seen that. What's an OO critic to do? :-)
  • I've been using this book for about 3 months, and I'm no Newbie to PHP programming but it's got some invaluable stuff in there.

  • ...if php would just include one tiny bit of perl goodness: "~="

    Instead, I've got to write ugly crap like "if (strpos($alltext, "This string") >-1)" in order to check if a variable contains a string.

    In Perl? "if ($alltext ~= "This string")". Much nicer.
    • ...if php would just include one tiny bit of perl goodness: "~="

      Instead, I've got to write ugly crap like "if (strpos($alltext, "This string") >-1)" in order to check if a variable contains a string.

      In Perl? "if ($alltext ~= "This string")". Much nicer.

      if (preg_match('This string', $alltext))

Math is like love -- a simple idea but it can get complicated. -- R. Drabek

Working...