On the PHPClasses.org blog there's a new post that tries to right some wrongs about how people think about PHP. Maunel Lemos looks at some of the misconceptions people have about the language and the truth behind them.

PHP is often a misunderstood language by people that either love or hate it. [...] This article attempts to clarify some of the most common wrong ideas that many developers have about PHP. Read the article to the end, so you may eventually start having a better perspective about PHP and take advantage of the opportunities that this language and the PHP ecosystem can provide you.

Among the misconceptions on the list, there's things like:

• PHP cannot do X (access memory, control hardware devices, or some unusual purpose)
• PHP is controlled by only one company (Zend)
• PHP is worse than Ruby On Rails, Python Django, X language Framework
• PHP is not good for high performance scalable Web sites or applications
• PHP developers are cheaper because they are not qualified

Iwan Luijks has a recent post to his blog trying to dispel some of the myths and misconceptions about becoming a certified ZCE through Zend's testing. He also includes some of the benefits of having the certification to go with your name.

In the community of PHP developers there are more non-certified professionals than certified professionals. PHP developers mostly don't really see the pro's of getting certified. These developers mostly honor the fact that PHP is a quick and easy language to learn and to get started with, and professionalism is found even by building a simple dynamic web page, leaving the discussion of whether this is a good or bad thing for what it is.

He talks about the confidence it can give current (and future) employers in your skill level and let them know you're the kind that keeps on learning/improving in your career. It also lets them know that you're dedicated enough to learn what you need to pass and can put it into practice easier in the future.

In a new post to his blog today Jordi Boggiano talks about a task that can trip up some developers when they're trying to secure parts of their site or just create one-time use tokens - making unpredictable hashes.

If you [override the default session handlers], unless you want to entrust PHP's core to do it, one thing you will have to take care of is generating unique session ids to send as a cookie to your users, allowing the session to persist. Other common use cases for such unique hashes is to generate CSRF tokens to insert in forms or URLs, and finally authentication tokens for email validation or such.

He talks about how we, as humans, aren't very good at figuring out true randomness and that hashing the information only adds to the problem. He mentions how some of the random functions in PHP aren't all that random and that there's a better way to really generate good values. He's come up with a solution (his "generateUniqueId" function) that tries to generate entropy from OpenSSL or from the COM extension or from the "/dev/urandom" on unix-based systems. It's then hashed and sent back out the other side for easy use.

Alvaro Videla has submitted a new post from his blog today that looks at caching in PHP applications, specifically with APC or memcached.

Sometimes when talking with developers I see that there are some misconceptions regarding this two caching systems. That's why I'd like to share some concepts I've learned along the way.

Alvaro looks at both technologies and describes what they're good at and two of the main misconceptions about them - that APC doesn't mean caching data and that using memcached isn't faster than working with local values (you still have to make the TCP round trip).

From the SellMix blog today there's a new post with a few "no-nos" and misconceptions when it comes to working with PHP in your applications.

We have all had that moment where we looked back on a script that we wrote years ago and thought "what the hell was I thinking?'". But it is a process. You make mistakes, you learn from those mistakes and then you move on. From my experiences of modifying other people's code, helping people on PHP help forums and making my own (many) mistakes, I hereby present this list.

There's eleven points included in the list, touching on things like:

• Superglobals being referred to inside class functions
• MySQL queries inside loops
• Brackets '" use them.
• Indent, indent, indent!
• Why are you using mysql_fetch_array?

Check out the rest of the post for more tips.

In a new post to his blog Johannes Schluter recommends that you don't use references in your applications, mostly because of some misconceptions about how they work.

Last year I spoke at eight conferences and attended a few more multiple times at most of them I found myself in discussions about references and PHP as many users seem to have wrong understandings about them. Before going to deep into the subject let's start with a quick reminder what references are and clear some confusion about objects which are "passed by reference."

He re-introduces referenced variables and scratches the surface about the confusion they can cause, not only on the user level but also in the internals of the language, and can lead to some unexpected results. He also mentions the "always passed by reference" idea that several PHPers have about PHP5 objects and why it's not entirely correct. He finishes off the post with a look at returning referenced parameters and how it can lead to bad application design.

Jani Hartikainen has started off a new series that looks specifically at the Zend_Acl component of the Zend Framework starting with this new post looking at a few of the misconceptions surrounding the component.

I'm going to be writing a weekly series of posts on Zend_Acl. This first post will clear up some common misconceptions regarding Zend_Acl, introduce creating ACLs for simple applications, and give some examples on using the ACL in both non-Zend Framework and Zend Framework applications.

To show the most basic usage (and set a foundation for future articles), he creates a simple ACL system for a Zend Framework application. The system sets up a few different roles (guest, member) and some rules to show who can access what. He ties this into his preDispatch method in his My_Plugin_Acl plugin so that it runs right before the rest of the request is processed. If the user is not allowed, it kicks them other to the authentication controller for them to log in.

Eran Galperin has a few misconceptions in web development posted to his blog today (for both front and back-end development).

Here's his list:

• OO code is less performant than procedural code
• The backend is the most important part of development
• Graphical designers are good at user interface design
• The existence of a superior programming language
• XML is more economic than a DB

While the others touch on some topics that could be PHP related, he focuses on it in #1. He points out that sometimes making classes and objects and interfaces and...well, you get the idea...is just too much and that procedural code can be the quick hit you need.

After listening to the FLOSS interview with Rasmus Lerdorf, Jacob Santos has some of his own comments and thoughts (and misconceptions) the interview brought out.

He covers it in a few different points:

• I Thought Rasmus Was a Jerk
• PHP History: Damn You PHP Manual
• Personal Home Pages or PHP Hypertext Preprocessor Namespaces in PHP 6
• Rasmus Still Works on PHP?
• Open Source Burnout

For each, he explains how the interview helped to set his thoughts straight, especially in his opinions of Rasmus himself.

PHP Magazine has posted the results from one of their previous polls today - this time asking readers what they think the largest misconception surrounding PHP is.

The International PHP Magazine conducted a poll over the week, asking for your opinion on 'The misconceptions surrounding PHP'. The options provided were:

• Java/ASP/Ruby/Python/Perl/C is better, and faster than PHP
• PHP does not scale well
• PHP has to write/read everything from a database
• PHP does not support shared memory
• PHP is not a compiled language
• PHP can't run for days

The results from the poll showed unanimously that the impression that Java/ASP/Ruby/Python/Perl/C are better and faster than PHP topped the charts. Coming in close are two options - that PHP doesn't scale well and that PHP isn't a compiled language (surprising).

Check out their latest poll for the week asking what the most common security mistake is.