Become a fan of Slashdot on Facebook


Forgot your password?

PHP Hacks 165

Michael J. Ross writes "Given the current popularity of the Web development language PHP, it makes sense that newcomers to the language have a large number of introductory and reference volumes from which to choose. But for the more advanced PHP programmer, there are far fewer titles that explain how to make the most of the language, by applying it to solve relatively substantial problems. One such book is PHP Hacks: Tips & Tools for Creating Dynamic Websites, by Jack D. Herrington. Read the rest of Michael's review.
PHP Hacks
author Jack D. Herrington
pages 468
publisher O'Reilly Media
rating 8
reviewer Michael J. Ross
ISBN 0596101392
summary Practical techniques and source code for improving PHP-based Web sites and applications.

The book was published by O'Reilly Media in December of 2005. Despite its title, PHP Hacks: Tips & Tools for Creating Dynamic Websites is clearly intended to show how PHP's capabilities can be extended beyond its most common usage for creating dynamic and database-driven Web pages, and can be employed in such areas as graphics, reporting, Web site testing, code generation, and even fun purposes (for those few programmers who find the former topics less than entertaining). The author, assisted by six contributors listed in the Credits section, manages to pack an impressive number of general programming ideas and PHP-specific topics within this title's 468 pages. The material is grouped into 10 chapters, each of which contains a generous number of "hacks," each in its own section.

As with most if not all of the other titles published by O'Reilly, this book has a Web page that offers an overview of the book, its table of contents, all of the book's code (in both Zip and tar file format), and a list of confirmed and unconfirmed errata. In addition, the site hosts five sample hacks (in PDF format): accessing iPhoto pictures, generating Excel spreadsheets, avoiding the "double submit" problem, reading RSS feeds on your PSP, and creating custom Google Maps. Perusing these hacks would give the prospective buyer a clear sense as to the style of the book's other 95 hacks, as well as the (low) level of PHP expertise needed to understand them.

The book begins with a preface that describes the organization, conventions, and icons chosen for the book. Also, it covers the legality of the code samples, lists contact information, and mentions O'Reilly's Safari online book service, which contains this title among many other PHP resources. What is perhaps most unique about this book's preface is that the author identifies over half a dozen weaknesses commonly seen in PHP applications, and explains how his book addresses those problems. In addition, he makes explicit how some of the hacks can be used for jazzing up one's Web site or Web-based application.

The first chapter discusses how to install PHP on Windows, Mac OS X, and Linux, and then verify that the installation was done properly. Herrington then briefly explains how to install MySQL and perform some basic database management. The chapter concludes with coverage of installing the PEAR library on your local machine and on your Web host's server (which is incorrectly identified as your "ISP machine," apparently assuming that most developers choose their Internet service providers for hosting their sites, when in fact the opposite is true). Since the typical reader of a non-beginning book such as this no doubt has one or more introductory and/or reference PHP books at hand, it would seem superfluous to waste time and space explaining how to install these components. But few pages are taken up by the material.

The next chapter is devoted to hacks that help to jazz up the design of one's Web sites, including how to create a skinnable interface, build a breadcrumb trail, create HTML boxes, add tabs to your interface, and other valuable techniques. Subsequent chapters offer hacks in the areas of dynamic HTML (DHTML), graphics and digital pictures, databases and XML, application and e-commerce design, patterns and PHP object orientation, testing and documentation generation, and building alternative user interfaces. The 10th and final chapter covers some "fun stuff," such as creating dynamic playlists, developing a media upload/download center, and even putting Wikipedia on a Sony PlayStation Portable.

Rather than try to explain in detail all of the many topics covered in the book, I instead encourage the interested reader to visit the publisher's Web page, and scan through the table of contents provided, to get a better idea as to how much of the book would be of interest to the individual. Also, the five sample hacks listed on the site, would be well worth examining and trying out. Overall, the topics chosen reflect favorably upon the judgment of the lead author and the other contributors to the book. The typical PHP veteran would likely be interested in most of the applications covered, and would probably learn some new tricks, especially in the areas of patterns and code testing, regardless of their level of experience.

Like all books, this one is not perfect. As with the first printing of most technical books; particularly those chock-full of source code; the book contains a fair number of errata, likely even greater in number than those reported and listed on the publisher's Web site, as mentioned earlier. Consequently, any reader who chooses to test the sample code and he or she would be encouraged to do so; should keep one browser window or editor buffer open and devoted to those errata, so as to minimize the time spent trying to figure out why some sample code is not working as advertised.

Some readers posting in forums have complained that the sample code has evidently not been fully tested on all platforms, nor in all Web browsers. Since few if any reviewers would have the time, resources, or inclination to verify these claims, it should suffice to simply bear in mind that the script output and other behavior detailed in the book might not exactly match those experienced during one's own usage of the code.

The fact that there were several cooks in the kitchen brewing up this particular book, is obvious from the way that the code formatting is not consistent throughout the book, as well as the variety of problem-solving styles. Fortunately, neither weakness is of much consequence, and the latter might even be considered a "feature," as it allows the reader to see how a number of veteran PHP developers approach solving a problem.

Most technical works written by a team of authors, end up as excessive "doorstops" that are often frustrating to read as a result of the wildly inconsistent writing and coding styles, to say nothing of the material often being out of date as a result of the long production time needed by the publisher. The opposite case can be even worse, when a publisher releases a book that was clearly thrown together as quickly as possible to capitalize upon a hot new trend in technology. Thankfully, PHP Hacks keeps the style differences to a minimum, and benefits from having a lead author responsible for the book as a whole.

Some programming purists may take issue with the use of the term "hack" used as a synonym for a small PHP application or the use of such for solving a problem, since the majority of the PHP scripts in the book do not involve any programming or problem-solving that would be considered notably clever or elegant. Yet the misuse of the term seems to be spreading, and is not limited to this particular book ; another example of marketing overpowering stability of language. In the preface of PHP Hacks, the author explains that he uses the term in the positive sense of creative participation, to help reclaim it from its popular usage in place of the more traditional term "cracking," i.e., breaking into systems.

Yet aside from these complaints, PHP Hacks is a worthy title that offers explanations and source code for many valuable site-enhancing applications, testing and code generation techniques, and critical e-commerce safeguards. I recommend this book to any PHP developer who would like to add to their Web sites' capabilities, as well as their knowledge of what PHP can do.

Michael J. Ross is a freelance writer, computer consultant, and the editor of the free newsletter of"

You can purchase PHP Hacks: Tips & Tools for Creating Dynamic Websites from 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 Hacks

Comments Filter:
  • by Anonymous Coward on Wednesday July 05, 2006 @05:13PM (#15663001)
    PHP is a bunch of hacks.
    • by Anonymous Coward
      I don't see why everyone is so critical of PHP. PHP does have its downfalls like any other programming language but there are a lot of things that make it so much easier. PHP has a lot of functions and although some people critisize this, it makes it much easier to accomplish many different tasks. I am a person who programs in PHP almost everyday and have been doing so very a few years now and I will admit that things such as magic quotes (though easily fixed) are a pain for beginners and worries such as
      • by PCM2 ( 4486 ) on Wednesday July 05, 2006 @06:47PM (#15663530) Homepage
        PHP has a lot of functions and although some people critisize this, it makes it much easier to accomplish many different tasks.

        In my experience, it's not so much a case of an embarrassment of riches but more like what the parent said -- it feels like a bunch of hacks. For example, standard library functions that seem similar in almost every respect, save that they work on different data types, take different parameters (or accept them in a different order). This can be very frustrating for experienced programmers who want to get up to speed quickly. Presumably it's less of a worry if you're just learning on PHP.

        I don't hate PHP. I don't really like it, either, though. I'm one of those people who is quick with a snide comment about it whenever it's brought up, just because it has always feels so amateurish, poorly designed, and slapdash to me. That said, you can do some pretty decent stuff given a database abstraction layer and Smarty templates (for example). And the one big advantage it has over Ruby on Rails is that it's available on just about every cheapie $5/month Web host around, whereas RoR is barely supported.

      • by VGPowerlord ( 621254 ) on Wednesday July 05, 2006 @07:26PM (#15663698)

        I don't see why everyone is so critical of PHP.

        PHP started out as a set of Perl scripts in 1995, presumably using the then-new Perl 5. When it became its own language in 1997, it somehow lost namespaces, the module loading system, DBI, use strict, and everything else in Perl that doesn't register on the suck-o-meter. It also did silly things like adopt the TCL global variable system, rather than using the one that C, Perl, Java, and even things like VB use.

        So, yeah, there's a reason every is critical of PHP.

        Sources: perldoc perlhist [] (perl 5.000 was released on 1994-Oct-17), PHP History [] (PHP/FI 1.0 was a bunch of Perl scripts released in 1995, PHP/FI 2.0 was written in C in 1997), DBI::Changes [] (First official DBI release was 0.58 released in 21 June 1995)

        • PHP is VB for Unix Weenies: fast, cheap, and sloppy. It is possible to write good code in php, it just isn't common.
        • by mcrbids ( 148650 ) on Thursday July 06, 2006 @03:23AM (#15665405) Journal
          So, yeah, there's a reason every is critical of PHP.

          I'm on the other side. What is it about a language that makes it *EASY* to consider the problem at hand, and doesn't make you worry too much about implementation details?

          Using PHP, you don't have to worry about things like memory management and/or memory type translation. A "1" becomes a 2 when you add a 1 to it.

          Arrays and hashes are the same. Any array can be accessed as a hash, any hash is also an array. Makes it easy to define data in memory, then do loops/recursion on it to get whatever result you want.


          Time spent solving customer problems rather than implementation problems is time spent making money instead of wasting it.

          I've written some really big projects with PHP. (EG: over 50,000 lines in 3+ years, with NO HTML CODE) It's done a magnificent job. It scales nicely and easily with it's "share nothing" approach [], and is highly reliable. In the 6 years that I've been actively developing with PHP, the number of times that there was a bug/problem with the language I could count on one hand, with 4 of the fingers peeled down. It's reliable and scalable enough that Yahoo uses it as their preferred development language. []

          And, as far as security, the vast majority of issues have been with idiots writing insecure scripting, which can be done in any language. (Yes, I'm thinking of you, SPAW editor!) And, if you're using a decent operating system [] with an update mechanism (EG: yum) then updates to fix found security issues is a no-brainer.

          With PHP-GTK you can write quick, powerful, cross-platform GUI applications with ease and speed [] - I've done so, managing a distributed database application among some 70 school districts with many hundreds of users - and it works marvelously.

          PHP may have it's warts, but it's a damned fine tool. Don't let anyone convince you otherwise.
          • I've watched a few people trying to program in PHP, and they all follow the same pattern: go to, find the function they want, write a bit of code, test. Go to, find, write, test. This was nice, they could just be learning, everything was fine.

            However, they were still having to look at the manual a month later. That isn't fine. Come on, you've been using PHP for a few weeks now, surely you can remember which function it is, how it's spelled, and what the arguments are by using it a fe
            • I'm not trying to defend the inconsistencies in PHP (you are right there), but if you feel you need to look at the manual all the time you need to use a better tool. Zend studio, for example, autocompletes function names and also tells you in which order to put the arguments. This is a huge timesaver if you're using PHP.

          • Using PHP, you don't have to worry about things like memory management and/or memory type translation. A "1" becomes a 2 when you add a 1 to it.

            Arrays and hashes are the same. Any array can be accessed as a hash, any hash is also an array. Makes it easy to define data in memory, then do loops/recursion on it to get whatever result you want.


            These are features of nearly every modern scripting language and are therefore nothing to brag about. The first feature is called weakly typing, and is known not
      • I don't see why everyone is so critical of PHP.

        An ideal programming environment makes it easier to do the right thing than the wrong thing, makes easy things easy, and hard things possible.

        The latter two PHP does a tolerable job on, considering what it is. It's not a good job by any means, but there are worse.

        Where people like me start bagging on PHP is that for a very long time, PHP just about forced you to do the wrong thing. Then, they'd fix the wrong thing by adding another wrong thing. Then, they'd a
    • PHP Object Oriented Programming => "POOP"
  • those persons whose technical acuities are slightly greater than "Script Kiddies". Maybe I just hate PHP.
    • You do (Score:5, Insightful)

      by Unski ( 821437 ) on Wednesday July 05, 2006 @05:31PM (#15663112) Journal
      it's just the fashion at the moment. Bashing Java is a classic, but PHP, like 80's ra-ra skirts and lip gloss, goes in and out of fashion constantly. Just stick to praising R-o-R, that'll keep the karma nice n' safe.
    • Maybe I just hate PHP.

      Spend a few months with ColdFusion and you'll love PHP.

  • by mcmonkey ( 96054 ) on Wednesday July 05, 2006 @05:19PM (#15663036) Homepage
    Also, it covers the legality of the code samples...

    And....? I presume if all the code samples were legal, such a statement would be unnecessary. I further presume such a statement to that effect would not warrant inclusion in a book review.

    So just what is the aspect of the legality of the code samples in need of clarification? Is one of the 'hacks' phishing with PHP? Adding free copies to your Kinkos card? Downloading launch codes from the WOPR? They're using the PHP to cook up meth, aren't they? *peer*

    • I'll try (Score:1, Informative)

      by Anonymous Coward
      I believe the article author is talking about licensing of code samples. That's always a problem with some books, there's no license for the sample code, so you have to if it can be used in any project or none at all. Having a clear explanation for using the sample code is sometimes nice when you're dropping some code from an example into your code to fix a problem you've been having.
  • In the preface of PHP Hacks, the author explains that he uses the term in the positive sense of creative participation, to help reclaim it from its popular usage in place of the more traditional term "cracking," i.e., breaking into systems.

    I hate historical revisionism like this. The traditional word for breaking into systems is HACKING, because breaking into systems was considering "clever", along with other clever usages of computers. Some busybodies decided that it gave hackers a bad name, and thus

    • Well stop using it. You just used it twice. I for one have stopped using the word "use" and any words that use it.
    • I hate historical revisionism like this.

      Yeah, no kidding. The reason this book is called "hacks" anything is not because the author sat down and thought long and hard about it, but because O'Reilly has branded entire line of books with the word "hacks." I doubt the author even had a choice in the matter.

    • Go back and re-read Steven Levy's "Hackers []". The usage of the term which matches the "hacks" books predates the "breaking and entering" usage.


  • Hacks? (Score:3, Insightful)

    by mikeal ( 968191 ) on Wednesday July 05, 2006 @05:24PM (#15663070)
    What defines a "hack" these days.

    Maybe I'm a bit bitter, and even at the risk of sounding like a troll I'm just gonna say it, isn't writing ANY decent amount of php kind of a hack.

    Personally I'm a django fan, I really respect the rails kids for what they are doing too. Once you start doing web development in a real dynamic language you realize that web development in php in most cases IS a hack.

    I've written lots of php over the years, and I'm so glad to know that I NEVER HAVE TO DO IT AGAIN. Unlike in other languages the "hacks" in php tend to be a necessity for doing development in the language. I've really tried to write "clean" code in php and it's just not possible for any project of a decent size.

    Any disagreements?
    • > What defines a "hack" these days.

      Any snippet that will move O'Reilly's new line of crappy shovelware books.
    • Re:Hacks? (Score:3, Interesting)

      by gamlidek ( 459505 )
      I don't disagree at all, but I must say that PHP is fairly popular and has its place. And tools are finally coming out that help organize the messiness of PHP, like Trustudio's PHP IDE. I think of PHP as kind of a quick-and-dirty approach to web development.

      • Re:Hacks? (Score:2, Interesting)

        by mikeal ( 968191 )
        I think you're correct about it being a "quick-and-dirty" approach, but I think usefullness of that breaks down once you realize that you have to maintain and continue to build the majority of web projects you create. Managability is key to being able to do that and I think PHP as a language fundamentally lacks that ability.

        One of the django guys quoted a Rails line which was "php is the devil" and went on to say "and it is, because it tricks you. They make it so easy to build out 90% of your web app, but t
      • Re:Hacks? (Score:4, Interesting)

        by drspliff ( 652992 ) on Wednesday July 05, 2006 @07:20PM (#15663667)
        Trustudio's PHP IDE is ok, but way behind the competition and hardly a finished product (their charging licensing for a beta version!).

        On the other hand I've been using NuSphere's PHPed and Zend's own ZendStudio for quite a while now, they both support remote debugging, the latest version of PHP, version control and code profiling and are both much more advanced and stable compared to Trustudio.

        PHP is no longer a baby language, and although it really annoys me sometimes (hello! no multiple inheritance or large integer/floating point number support) big real world applications are being written in it and most times I consider it much cleaner than Java when you know what you're doing.

        It's the age old thing, if you make it easier for good programmers to program, they'll get working code out of the door with much less bugs compared to a stricter language. It's quick and at times dirty, but it's understandable, you can apply [insert buzzword here] with little to no effort and it runs on most of the world's web hosting servers.

        For example, move from C to C++ and you will almost certainly be more productive, from C to D, from C++ to Java, from Bash to TCL, from Java to PHP.. you get the picture. When I've got a tight deadline and lots of features to implement, I'm going to want to do it in whichever language is most productive, this is why you see people adding backend JavaScript/BSH support to their J2EE webapps *laugh*.
    • Re:Hacks? (Score:1, Insightful)

      by Anonymous Coward
      I disagree, you probably just couldn't figure out "how to" hack it to make it work for big projects.
    • My view of a hack is an implementation without a design. Typically hacks are done by very intelligent people that can many times succeed without doing any design work at all. The doesn't mean doing a design is for dumb people, or hacking is necessarily bad. There are times when hacks are legit, and times they should be avoided. I'd get into those topics but they are getting a pinch off topic and would be long winded.
    • Any disagreements?

      Well it is possible to write clean PHP code when your working on tiny projects. Tiny projects are fun, I do them sometimes in my spare time.

      I don't get why people continue to whine about how bad PHP is for large websites. We know that it's a bad choice for that kind of thing, that's because it's not designed with that kind of thing in mind. However due to being easy to set up and deploy PHP is good for small quick fun projects.

      So either your an all work no play kind of guy, or your to

      • I really think PHP5 changes a lot of that. I am building a couple of apps right now in php with front controllers and a true MVC arch. With php 5 you can create a command factory or whatever cool stuff you need. Caching is still a sore point, but I think it is a very powerful tool for small to medium size projects. When the projects get huge....maybe not so much, except maybe Yahoo style with PHP as a front end language and the back end in Perl/Python and c++.
      • IMHO if an idea has merit it's only a certain amount of time before it gets big. Besides, I find programming in python with django much more fun. It's funny the way php tends to get touted for enterprise web sites.
    • I too use Django, I'm dissapointed at the lack of a djangoforge though. Still, overall I enjoy it a lot more than php (which I have a work experiance job doing, kind of happy that I managed to get a programming one, a wee bit pissed off its in php).

      Django is super duper awesome, it would be good if there was a book like "Django Patterns" or something because I was a little bit unhappy using template tags at first but then it just started working for me.
  • 1. Install Drupal.

    OK, I'm good to go!
    • That is precisely why people do use PHP

      I do not like PHP much and if I was going to write a CMS from scratch I would not use it.

      But I do not need to write a CMS from scratch. I can use an existing one. I may have to write an extension/module/plugin if I have special requirements.

      It may not be as clever as writing your own CMS, but it is a lot less work. It suits me. I can put up with PHP in the circumstances (i.e. when the best CMS for my purposes is written in PHP).
      • Yes, I do realise that this begs the question of why the developers who wrote the CMSs I use choose PHP. I have two responses to that.

        1) PHP is available with most shared hosting packages, it has lots of useful functions and has extensive libraries.
        2) Ask them.
    • 2. ?????
      3. Profit!
  • I thought maybe it would explain the constant hack attempts on non-existent php apps on my webservers.

    [admin@bsever logs]$ tail -100000 access_log |grep php -i |wc -l

    2% of last 100K hits. I run no php on it + this is a test server that is not linked to anywhere public.

    For example: - - [04/Jul/2006:00:37:03 -0700] "GET /articles/mambo/index2.php?_REQUEST[option]=com_co ntent&_REQUEST[Itemid]=1&GLOBALS=&mosConfig_absolu te_path=
    • by Nos. ( 179609 )

      Yup, but this comes down to what all dicussions do when a PHP topic is posted to slashdot. Is it the fault of the language when a lot of open source applications are written poorly? There have been very few vulnerabilites in PHP, but lots in apps like Mambo, *Nuke, phpBB, etc.

      I like PHP, I can develop stuff very quickly in it, and I know how to secure code against CSS, SQL-Injection, etc. There are shortcomings with it, like basically every other language, but I don't think the fact that all these app

      • Well said. Too many PHP apps are developed from the perspective that "Well I wrote the data to look like $X, so it will always come in as $X" - and as someone without any formal CS/programming training beyond an introductory C++ course, I really wish those PHP "experts" would protect against such easy vulnerabilities. Just because your machine makes square pegs, and the hole is square, doesn't mean I'm not going to try to shove a slightly smaller triangular peg in it.
      • There are shortcomings with it, like basically every other language, but I don't think the fact that all these application with vulnerabilities should be a direct reflection on the language itself.

        Well yes and no. I mean, PHP does have some braindead configuraion options that result in insecure code. Writing code that's secure with register_globals on is more work than just turning it off. Likewise handling both cases of magic_quotes_gpc is just a pointless hoop to have to jump through.

        I don't really bla
      • by dedazo ( 737510 )
        Is it the fault of the language when a lot of open source applications are written poorly?
        Why not? That's the reason why Visual Basic was considered "worthless", as if it were inherently impossible to create something useful (well documented, maintainable, stable, etc) with it.

        Not that I agree with either view, but it seems to me PHP is no better than Visual Basic in this regard.

      • by FooAtWFU ( 699187 )

        Is it the fault of the language when a lot of open source applications are written poorly?

        Yes. The language doesn't actually compel you to write insecure code, but it would be hard to imagine one which came closer. It's practically begging for injection everywhere. You need to manually escape everything. Database work? Sorry, no prepared statements. Going to send mail()? Leave a few newlines in the wrong variable and you can turn your form into a lean, mean spamming machine! Going to try and call system

        • Is it the fault of the language when a lot of open source applications are written poorly?

          To an extent yes, but it's one of those things that anybody with a clue will get past very quickly and get to a stage where these things are avoided. But you're forgetting that compared to Perl and the absolute crapload of different libraries available in the CPAN repository, you're essentially programming on a skeleton framework, much like Perl quite a few years ago.

          I'm not trying to defend PHP - there are some

        • by lbft ( 950835 ) on Wednesday July 05, 2006 @10:45PM (#15664507) Homepage
          Database work? Sorry, no prepared statements.

          PHP has had prepared statement support for MySQL since 2003, it's been emulated in PEAR for an eternity and the very useful PDO extension provides an abstracted interface supporting prepared statements to SQL Server, Sybase, Firebird, Informix, MySQL, Oracle, PostgreSQL, SQLite, DB2 and ODBC.

          (and of course, you HAVE to use the shell.)

          Forgive me, but you don't know what you're talking about. There is almost never a need to call external apps from a PHP script. The most common needed external app is ImageMagick (because sometimes GD doesn't provide all the functionality you need.) Even then, there are at least two PHP extensions to deal with ImageMagick directly, as well as a PEAR package to abstract away from the image processing library/app.

          Quick check: do you want escapeshellcmd, or escapeshellarg?

          Well, I dunno, do you want to escape an entire command so that multiple commands can't be injected or do you want to escape a single argument so that multiple arguments can't be injected? Heaven forbid that you should have to spend ten seconds checking the manual [] pages []...

          Going to send mail()?

          So use one of the multitude of classes specifically written to encapsulate mail sending (including, shock horror, one in PEAR.)

          two words should make your skin crawl: "register globals"

          register_globals has been disabled by default for six (6) years.

          It's not the fault of the language that you didn't bother to keep up with how to use it as it evolved.

          • Forgive me. With regards to my assertion "you HAVE to use the shell" I had been referring to the convenient ability of many-languages-which-are-not-PHP to call a command outside PHP without invoking, say, bash (a shell). Which avoids the pesky shell-metacharacter processing, instead of merely trying to escape things. (But that's not the PHP way. The PHP way to carry water is to give you a collander, instead of a bucket, and require that you plug the holes yourself.)

            It's not the fault of the language that

        • "The language doesn't actually compel you to write insecure code, but it would be hard to imagine one which came closer."

          C? (Ouch, my poor karma -- but seriously, memory management is a security vulnerability in the hands of the average programmer AND every programmer thinks they are above average).

    • That's a *Mambo* hack attempt, not a *PHP* hack attempt.
  • by bsartist ( 550317 ) on Wednesday July 05, 2006 @05:46PM (#15663225) Homepage
    "Advanced PHP programmer"? Now there's a contradition for you.
    • I was actually pretty surprised to see this book. Assuming that this is the same Jack Herrington that I once knew (and I'm pretty sure it is), he's pretty big into Ruby. Or at least he was. Didn't know he had a background in PHP.
    • One of the highest paid coders I know uses php.......

      Personally I wouldn't touch it, not my kind of coding, but you have to admit it's good stuff.

      Also, lets not forget that there's a lot of very complex code underlying php, and the guys who wrote that simply *are* very good at what they do. Advanced is a word I'd be comfortable with.

      You don't find that kind of talent everywhere, but where you do we all benifit by getting to do things in a simpler way.

      • One of the highest paid coders I know uses php.

        Judging by that benchmark, Bill Gates would be classified as the world's best programmer.

        Also, lets not forget that there's a lot of very complex code underlying php

        Complexity is not always a benchmark of programming skill either. Sometimes it's a sign that the programmers didn't have the skills to come up with a simpler, more elegant design. Having said that, I've never looked "under the hood" of PHP, and I don't know the programmers. I'm not sayng they

    • Exactly. When I saw "PHP Hacks", I thought the people behind PHP-Nuke had written a book.
    • ...Now there's a contradition for you.

      Now there's a slashdot 'speler' for you... ;-)

    • by LordLucless ( 582312 ) on Wednesday July 05, 2006 @07:51PM (#15663800)
      A contradiction, sort of like a person who has a grammar nazi post in their sig, but can't spell contradiction?
  • by ardor ( 673957 ) on Wednesday July 05, 2006 @05:46PM (#15663230)
    anyone can tell me if this is to be taken seriously, or rather seen as worthless php-bashing? []
    • Draw whatever conclusions you like, but the linked page is accurate.

    • Those are all valid concerns, although with some heavy Perl bias. Of course, the PHP problems pointed out are generally being worked on - but you have to move slowly because of the installed base (who also generally don't upgrade very often).

      That said, I am definitely in the market for a new language to build sites with. Perl ain't it as I've been there and done that. Great language but I would rather maintain/fix crappy PHP sites than crappy Perl sites.
      • "I am definitely in the market for a new language to build sites with."

        To clarify: I'm a professional PHP developer but finding the language doesn't grow with me as a grow as a developer. Looking into RoR but the hype scares me (memories of Java).
      • That said, I am definitely in the market for a new language to build sites with. Perl ain't it as I've been there and done that. Great language but I would rather maintain/fix crappy PHP sites than crappy Perl sites.

        If you are looking for something that still retains most of the useful parts of perl then RoR, or one of the other Ruby web dev frameworks (yes, they do exist) might be the way to go.

        Personally I am happy with Python, especially considering the community is really starting to get behind WSGI,

    • It's all true. Now, I know Perl has its own set of issues, and as far as speed is concerned you can't expect plain vanilla CGI to favorably compare to decently cached PHP in a DSO module for Apache (though you CAN run spiffy-fast with things like mod_perl or FastCGI, especially if you're willing to leave Apache for lighttpd like the Ruby on Rails people like). And of course you can write some really incoherent stupid code in Perl, certainly -- especially when you're not smart enough to realize there's somet
    • All of those observations are true, but that doesn't mean you shouldn't use PHP. As with any tool, you must consider the user, their skill level, and the project requirements when making your decision.

      Many of PHP's inconsistencies stem from the fact that it is an open source language. While it has likely changed now, many functions were accepted into the source without anyone ensuring a consistent naming scheme, parameter order or behavior. To maintain backward compatibility for what is now a very large use

    • I have used both perl and PHP extensively for web development. The reality is that perl may seem like an academically better language but it scales like ass in the web environment. Modperl sucks huge amounts of memory (an httpd process will remain the size of its largest allocation) and FastCGI is almost as bad. I absolutely hated PHP when I started using it, but its performance is undisputable and with the release of version 5, the OO support just makes the language feel far more "correct" than Perl.
  • Has anyone tried the CakePHP package? It's supposed to be similar to RoR, but i'm unable to deploy a Ruby based solution at work due to stupid policys (like: everybody knows php, nobody knows ruby... pfff). If not, are there any rails-like project for PHP anyone care to recommend?

    • Rails is great. Not just for web sites but for all types of programming because it really encourages you to use best practices like unit testing, MVC etc. Capistrano and migrations also rock.

      The only problem with rails is that ruby is not ideal for windows, the interpreter has threading issues, you can't write COM objects with it, and it's the slowest of the big scripting languages.

      Having said all that none of the rails clones come even close. Every language has now attempted to make a rails clone and they
    • We're using it for a project at the moment. seems like every problem we run into isnt a problem in rail, but dont worry, there are plently of ugly, unoffical hacks, to get most things to work some of the time.

      grumbles at the stupid people who made us use cakephp because they knew php and didnt want to learn something new
    • I am currently porting a classic PHP site to CakePHP and I must say the framework makes life a lot easier. It takes some getting use to MVC design practices (eg a view doesn't request data, it is given data) and some of the documentation is a bit unclear but once you get into the swing of things it's a rapid way to develop sites.
  • Despite what? (Score:2, Insightful)

    by JudgeDredd ( 561957 )
    The book was published by O'Reilly Media in December of 2005. Despite its title, PHP Hacks: Tips & Tools for Creating Dynamic Websites

    Umm, despite its title, what?
  • PHP Popularity (Score:2, Informative)

    by hotfireball ( 948064 )
    "Everything populair is wrong" -- Oscar Wilde
  • by Anonymous Coward on Wednesday July 05, 2006 @07:07PM (#15663615)
    Yes, PHP is relatively easy to begin coding in, what with its fairly forgiving variable typing (or what some would call non-typing) and its babysitting of memory. I would even agree that PHP tends to attract more bozos and wannabes for this very reason. However, PHP is, and continues to be the most widely used non M$ language for open sourced web applications. This is because it works. Sure, PHP allows sloppy coding, but it also allows clean and well written code. PHP is a lightweight, nimble, comprehendable scripting language that is very well suited for its intended environment: the web.

  • Free PHP bashing (Score:4, Insightful)

    by Beuno ( 740018 ) <> on Wednesday July 05, 2006 @08:29PM (#15663930) Homepage
    I understand that PHP has a very solid newbie user base, but let's not forget monstrous sites like Digg and Wikipedia run on PHP + MySQL
  • Uhhhh (Score:2, Insightful)

    by Anonymous Coward
    Did any of you failed PHP programmers ever think maybe its your own ability to write well formed code?

    Since many of the largest and most complicated sites in the world use PHP flawlessly, I think its just your amateurish programming style requiring a compiler to bitch slap you till you do the right thing. That's like blaming the razor blade company when you finally relive us PHP programmers from having to listen to your bitching by committing suicide. Just because you have the freedom, doesnt mean you sho
  • by linvir ( 970218 ) * on Wednesday July 05, 2006 @10:26PM (#15664424)

    PHP seems to be one of those red-button topics on Slashdot. If the word even appears in the text of the story, the topic at hand is dropped entirely in favour of having a big wanking session [] and patting each other on the back for knowing a 'superior' language, or for having been into Linux 'before it was cool', or whatever the general topic happens to be.

    And not only is this stuff offtopic, it's also just so painfully redundant. I swear, that Slashdot story generator page [] from a while back was pretty impressive, but I'm starting to think maybe I could cook up a Slashdot comment generator as an add-on.

    // Wooooooooo! Watch out for magic quotes!

    // And now for a basic example of some comment generation
    if (strpos($story, 'DRM'))
    echo 'DRM is bad.' . "\n";
    while (strrpos(date('l'), 'y') === 0) // what a FUKKEN MESS111
    echo 'Yes, DRM is very, very bad indeed.' . "\n";
  • What a coincidence (Score:2, Insightful)

    by petroele ( 81470 )
    I just bought this book last week. I'm mainly a C++/Java guy but I've been doing lots of PHP over the last year or so. To stay on topic, I was fairly happy with the content of the book. Probably about half of it was stuff I already knew or stuff that was useful but really not PHP specific (DHTML, Javascript, OO design patterns). But there were also quite a few useful hacks that made it worthwhile. Overall, it is good book for thumbing through in your spare time to pick up some new tricks.
  • I don't know, PHP may have its faults, but I enjoy working with it: []

Research is what I'm doing when I don't know what I'm doing. -- Wernher von Braun