Following several other posts with the "common mistakes PHP developers make" theme, Bruno Skvorc has posted his own list of seven things he sees developers doing over and over.

Back at the end of June, TopTal, the freelance marketplace, published a post about 10 Most Common Mistakes PHP Programmers Make. The list wasn’t exhaustive, but it was well written and pointed out some very interesting pitfalls one should be wary of – even if I wouldn’t personally list the mistakes as very common. I encourage you to give it a thorough read – it has some truly valuable information you should be aware of – especially the first eight points.

His additions to the list of common mistakes includes:

• Using the mysql extension
• Not rewriting URLs
• Assigning in Conditions
• Being Too Transparent

You can read the full list and summaries of each in the rest of the post.

Gary Hockin has a new post to his site talking about how he's found that less is more when it comes to what to include in your "composer.json". He works through some of his own opinions on the matter and suggests a bit more thought before just including another library.

I have absolutely no doubt this post will be largely disagreed upon by many in the PHP community, but I’ve had a terrible day and I’m hoping that the process of just getting this off my chest will be therapeutic in some way. [...] So, today I sat down and started writing the tests for our new lightweight SDK that offsets much of the work needed in the delivery of the adverts to workers via a Beanstalk queue. It should have been so easy. Things went well for the early part until I realised that I wanted to be able to extract and serialise our Device object to put it into the queue, and then hydrate it back into a Device object inside the worker

He assumed that since he'd used Zend Framework 2 a good bit and there were no (declared) dependencies, he could directly use an individual component. Unfortunately, there was a dependency (ZendFilterChain), requiring another package to be added via Composer and pulled down. He points out that Composer has made this almost too easy and developers maybe aren't as thoughtful about the libraries they pull in because of it.

He makes a call out to developers to remember the idea behind the MicroPHP Manifesto and really think about the code they're puling in, how large it is and if it's what they really need. He's not suggesting that Composer is the problem, rather the blind usage of it without thinking through the implications.

In this post from the SitePoint PHP Blog, Harry Fuecks shares information about two more framework systems for PHP - Tonic and Code Igniter.

Yes I know—with the framework in progress, we don't need no more stinkin' frameworks. Except there's a couple I've seen recently which are noteworthy. I haven’t delved into the source code in any depth—exploring framework code bases has become as much fun as watching paint dry, but there are some interesting ideas here, if you’re looking to new angles on the problem.

The "new angles" he mentions are:

• For Tonic, the fact that it's a "RESTful" environment and feels like web.py in its development
• And for Code Igniter, because it has a "Rails-esque" with an interesting approach to URL mapping.

In this post from the SitePoint PHP Blog, Harry Fuecks shares information about two more framework systems for PHP - Tonic and Code Igniter.

Yes I know—with the framework in progress, we don't need no more stinkin' frameworks. Except there's a couple I've seen recently which are noteworthy. I haven’t delved into the source code in any depth—exploring framework code bases has become as much fun as watching paint dry, but there are some interesting ideas here, if you’re looking to new angles on the problem.

The "new angles" he mentions are:

• For Tonic, the fact that it's a "RESTful" environment and feels like web.py in its development
• And for Code Igniter, because it has a "Rails-esque" with an interesting approach to URL mapping.

Via our sister site, AjaxDeveloper.org today, there's a pointer to this post on Jim Plush's blog - "AJAX, PHP and Javascript Errors - How to get more data".

Javascript is a powerful tool in the web programmers toolbox however, it's also one of our greatest headaches. Dealing with browser inconsistencies is always a source of great pain. You test on multiple platforms, find everyone you know with a mac running safari and think you have your code locked down however it rarely always works out this way. Being able to detect javascript errors in the wild can be a great resource for you to really see how your code is performing on a day to day basis.

The key to it is that it uses a global function that IE and Mozilla both have to create a global-level error handler for the page - "onerror". He shows you how, with a few simple lines, you can create the function (with an alert inside) and, together with a little bit of Ajax and PHP magic, write it out to an error logging script for review...

Via our sister site, AjaxDeveloper.org today, there's a pointer to this post on Jim Plush's blog - "AJAX, PHP and Javascript Errors - How to get more data".

Javascript is a powerful tool in the web programmers toolbox however, it's also one of our greatest headaches. Dealing with browser inconsistencies is always a source of great pain. You test on multiple platforms, find everyone you know with a mac running safari and think you have your code locked down however it rarely always works out this way. Being able to detect javascript errors in the wild can be a great resource for you to really see how your code is performing on a day to day basis.

The key to it is that it uses a global function that IE and Mozilla both have to create a global-level error handler for the page - "onerror". He shows you how, with a few simple lines, you can create the function (with an alert inside) and, together with a little bit of Ajax and PHP magic, write it out to an error logging script for review...