Ian Selby's Blog: Weird PHP Seg Faults & Custom Session Handlers
306188
In recent work, Ian Selby came across something odd - a setup where PHP was segfaulting without any real indication of where the error might be:   Starting to get a little frustrated, I took a peek at my error logs (/var/log/httpd/error_log for the unitiated), and discovered a wonderful message [about the segfault]. As any person scratching their head would do, I hit up google.. to no real avail. Just a bunch of php bug reports. So, what happened, and how did I fix it?   After searching through the code and narrowing down where it could be, the culprit looked like a custom session handler he was using. It uses MySQL to store the sesion information and, unfortunately, when Ian had compiled the server he didn't let PHP know about his unique setup.   His default installation was trying to use the default MySQL information (including the socket) to reach the database. Obviously failing, the server simply gave up and segfaulted. Thankfully, all it takes it a recompile with a few extra parameters and you're back in business.
629310
You cannot help but like someone like Greg who is honest and humble:  "I am one of the core developers of the PEAR package who has joined the game relatively late... The base PEAR class is one monstrous mistake, and PEAR_Error is pretty close. Everyone knows this. I designed an error class that is much, much more flexible and it is part of PEAR 1.3.1 (PEAR_ErrorStack) - check it out. "  Sadly it's just not true that everyone knows that PEAR class is big mistake (Jeff Moore has more on why PEAR.php is awful).  Given that PEAR is both an important framework and a worthless class, the confusion in names will  definitely  cause the value of the PEAR class to be overestimated. Just read any article on PEAR and you can see what nice words they have to say about the base classes :-(     I once said once that too many PEAR developers were journeymen. This might have offended  some people, but I was trying hard to be diplomatic. I must say that today the PEAR group is definitely more mature, and they have learnt a lot about library design. What would really make my eyes light up  would be an PEAR2 initiative that kept the existing classes, but dropped the bad seeds such as PEAR.php (e.g. the PEAR and PEAR_Error classes).   And in case you were wondering, I do think there's great value in the PEAR DB API. API's are important for interoperatability. For example, ADOdb has a PEAR DB compatibility mode. I would certainly be flattered if PEAR DB had an ADOdb compat mode too :-)
596569
With a bit of a rebuttal for Harry Fuecks' statement that PHP has a great lack of international support comes this new posting from John Lim at PHPEverywhere.
649335
Michael Kimsal has posted some more thoughts on what he calls the "sad state of PHP development" pointing out some of the practices of the PHP group surrounding the development of the language.   Every few months there's a release, whether large or small, which introduces new features and bug fixes. However, with every release also comes fears of tiny, sometimes undocumented, changes that break existing code, and often for no solid reason other than someone with commit access decided they liked the 'new' way better than the old way.   He points out a specific example, get_object_vars and how its return values were changed in an earlier release as well as the update to glob made recently to change its return types.    In his opinion:   No changes should be made to the PHP core without an issue being opened, either in the 'bug' tracker or some other issues tracker.   Be sure to check out the comments for other great opinions on the topic.
415712
To set things right about a misquote on Slashdot, Zeev Suraksi has posted this long statement mentioning what he really said and a few more personal opinions.   I've just been misquoted on Slashdot, as if I said there are no security problems in PHP itself, and that I instead point my finger only at inexperienced developers. If you read the original article on Heise Security, you'll see that I have not said anything of the sort. [...] I believe this is the belief of most others on the security team, but I'm only speaking on behalf of myself and do not represent them.   He also covers five more points pertaining to the article and the situation:  Where the bugs/problems lie with problems in PHP Why there are security problems in web PHP applications Why the current security level can be partially blamed on the language itself An admission that yes, there are security problems in PHP And the track record the PHP developers have had in fixing these issues  There's much more than just these brief highlights here, so I encourage you to head on over and check out the full post for yourself.   There are some other opinions on the matter from a few others out there too:  cyberlot's blog Zend Developer Zone's post Tony Bibbs' blog
242658
Popular posts from PHPDeveloper.org for the past week:Sebastian Bergmann's Blog: Support for the Cancel Case Workflow PatternCommunity News: The PDO v2 ProposalSite News: Popular Posts for the Week of 01.25.2008ProPHP Podcast: PHP Newscast for 2008/01/24Developer Tutorials Blog: Why you should be using YAML for configJob Posting: InvestorGuide.com Seeks Web Developer (Fairfax, VA)Pierre-Alain Joye's Blog: Debugging symfony (or any php script) with vim and XdebugCIO.com: You Used PHP to Write WHAT?!Demian Turner's Blog: Seagull 0.6.4 Release (fixes Security Isse from 0.6.3)Developer Tutorials Blog: PHP Qualifications: The Good, The Bad and The Ugly
273337
Here's what was popular in the PHP community one year ago today:Job Posting: National Auto Warranty Seeks MySQL DBAJob Posting: National Auto Warranty Seeks PHP Web App Developer (Wentzville, MO)DevShed: Creating a Login Script for a PHP Invoicing SystemZak Greant's Blog: The eZ partner program (response to Seth Gottlieb's Commercial O/S business post)php|architect: Application-level Logging with the Zend FrameworkPaul Reinheimer's Blog: Object-Oriented PHP, Concepts, Techniques, and CodeRyan Malesevich's Blog: Fight Spam Comments with Bad Behavior and AkismetZend Developer Zone: SQLite: Lean, Mean DB MachineBuilderau.com.au: Cache PHP scripts with APC modulePro-PHP Podcast: Interview With Cal EvansSitePoint PHP Blog: PHP extension for Cairo graphics libraryTechnobabbler.com: making a radar loop with PHPDevShed: Working with MySQL Result Sets and the Decorator Pattern in PHPJob Posting: exhibit-E Seeks Interactive Developer (New York, NY)Jacob Santos' Blog: Patterns for PHP: Page Controller Draft
217574
As mentioned by Ed Finkler, there's a list of signs your PHP needs refactoring from Soledad Penades.    I have had to go through a php application recently which has given me more than one headache and has required me to use all my possible patience. While working with it, I thought This is good material for an article, so that nobody else does the same in the future, and nobody else will need to experience the same displeasure as I have had to.   So here are the signs your PHP application needs a serious refactoring, right now    Included in the list are things like:   Uses global variables Everything's an array The neverending switch Interface inconsistency   It hits on one of the thing that bugs me too, the problem of "Brackets galore" - so many subarrays that you have to resort to three or more sets of bracketed keys to get to the value you want. It's bad enough trying to follow someone else's code without having to "trace down" an array to figure out which of the values they're talking about.
228837
Stefan Esser takes a look back at the first week (or so) of the Month of PHP Bugs he's doing for the month of March:   We are on day 5 of the Month of PHP Bugs, meanwhile details for 11 Vulnerabilities were disclosed, including 2 Bonus vulnerabilities covering local root vulnerabilities in the Zend Platform.   He mentions that, on the whole, the reaction has been positive, with those few out there that have their own thoughts on the bugs (such as one issues causing two bugs or that other bugs aren't viable because they're not included in a released version of PHP).
48646
In this new post to the PHP Security blog, Stefan Esser points out that an issue that was previously marked as corrected - a problem with the chunk_split function - hasn't completely been corrected.   This [bugfix] fixes the chunk_split() overflow (found by SEC-CONSULT) that was according to the PHP 5.2.3 release notes already fixed. The original fix was however not only broken but complete nonsense. If you can read C you will see that the integer overflow was not fixed in PHP 5.2.3 but simply moved into a separate line and an additional bogus if clause was added.   Stefan includes a simple four line code example to illustrate his point.
690580
On the Dotvoid.com blog today, there's a new post that shares some handy code to parse out information from the incoming user agent string for the visitors for your site.   Recently I experimented a bit with an Apache log file analyzer written in PHP. It's not all that difficult were it not for trying to parse the browser, or user agent, string. [...] For my purposes I don't care much for the operating system details. This is the result so far. I'm still not very satisfied but I thought maybe other people might be interested and maybe help out.   He provides the code in the format of an encapsulated PHP function that returns the product they're using, the version number of the browser and other various comments.
647305
Popular posts from PHPDeveloper.org for the past week:Ian Selby's Blog: Uploading Large Files With PHPONLamp.com: Quick and Clean PHP FormsDotVoid.com: Reordering nested sets using PHP and JavascriptRob Allen's Blog: Zend Framework Book Coming SoonCommunity News: php|works Daily Summaries (Day 2)Community News: Sara Golemon & Christopher Jones - First Day Summaries of php|worksJob Posting: University of Wisconsin, Department of Medicine Seeks Web Developer (Madison, WI)Zend Developer Zone: PHP Abstract Podcast Episode 19: Glue Frameworks vs. Full Stack FrameworksStefan Mischook's Blog: Installing PHP and MySQL on the Mac with MAMPSecurityReason: Three Advisories for PHP 5.2.4 (dl, iconv_substr & setlocale)
763575
Ilia Alshanetsky posts today about the proposed "Month of PHP bugs" that Stefan Esser is proposing:   It would be interesting to see what issues he discovers, hopefully most of them have already been reported to the PHP Security Team, in which case the upcoming 5.2.1 release will provide a resolution path for affected users.   Hopefully, as Ilia states, the bugs will not turn out to be zero-day vulnerabilities and will instead be smaller issues. Either way, a bug-fix patch will probably soon follow.   Either way, I have to look at this as a free security audit of PHP by someone with a clue about security and ultimately, in the long run it will only make PHP better, even if March is going to be rather busy.
698334
Popular posts from PHPDeveloper.org for the past week:The Bakery: Six New Articles/Tutorials PostedEvert Pot's Blog: PHP: Arrays vs. ObjectsDevArticles: Learning AJAXInternet Super Hero: PHP: mysqli_fetch_all()David Coallier's Blog: PHP Namespaces (Part 1: Basic usage & gotchas)I/O Reader: 15 Cool Things & 12 Things to Dislike About PHPProPHP Podcast: Newscast - August 16, 2007PHPBuilder.com: Dynamic XML with PHPSite News: Popular Posts for the Week of 08.17.2007PRADO Watch Blog: PRADO Watch: Interview With Timani Tunduwani - Why I Moved From CakePHP to PRADO
194115
On the PHP Security Blog, there's three new posts that Stefan Esser has written up that demonstrate some of the more destructive uses of Javascript that he's found:  JavaScript/HTML Portscanning and HTTP Auth Bruteforcing HTTP Auth in Firefox with JavaScript JavaScript Scanning and expose_php=On    While the first two are interesting, it's the last of these that most directly applies to PHP. He gives a simple "proof of concept" that checks to see if the embedded image is the correct "size" to be related to a webserver running PHP with the expose_php setting set to "on".
139275
Popular posts from PHPDeveloper.org for the past week:PHP-Coding-Practices.com: Try-Catch Syntax WeirdnessPHPBuilder.com: Cross-Platform Database PHP DevelopmentIBM developerWorks: Java and PHP technology on AIX - Integrate the Java business application w/ DB2OpenSourceCommunity.org: What do you think makes a good CMS?Jonathan Snook's Blog: Elemental: Conditional Content with CakePHPDevShed: The Basics of Using the Factory Pattern in PHP 5Builder.com.au: PHP exploit code plants itself in GIFJohn Cox's Blog:  Linux.com Now PHP PoweredNick Halstead's Blog: Solving Programming ProblemsPHP-Tools Blog: Testing FIT
449834
Sebastian Bergmann has posted the results of some benchmarking on the compilation he's done on the branches of PHP from version 3.0 all the way up to 5.3-CVS.   As people keep asking me for an update to my previous benchmarks (PHP / GCC / ICC Benchmark, PHP 5.1 / GCC Benchmark (Update), and PHP 5.1 Performance, I quickly ran a new benchmark today.   He rendered the results out into a series of charts defining the number of total seconds taken for the compile and how long each of the components took. It's impressive to see how much of a jump there was between the 3.0 series and 4.3.   He also includes his compile settings (and machine information) as well as the numbers for the results if you'd like to graph them out yourself.