The reason why I'm here is that, on occasion, a person decides that it's time write Yet Another PHP Bashing Post. Typically, this is followed by a bunch of Posts Defending PHP. [...] Saying that PHP is horrible or great is no more useful than saying that a hammer is horrible or great (regardless of the number of claws it comes with). [...] The real question is whether PHP - or any other technology - is good for you.

He goes on to mention current successful projects that use PHP, but focuses on the people and the ideas that made them happen, not the language "behind the scenes". He also comments on what he thinks makes a good programmer (and one that has matured past the "X language is the best!" stance):

And this brings me to the crux of the matter: The trick to being a great programmer is to learn as much as you can about as many programming languages and techniques as you can. Eventually, you'll learn that any language is excellent at some things, good at others, and a poor choice for many others. It's all about the context, and finding the right tool for the job.

If you are a serious PHP developer and have not given debugging a fair chance, or a chance at all, you are killing yourself. So let's do this thing from the ground up. WAMP, XDebug, IntelliJ, and magic. Follow these steps (for Windows) to reach my recent state of elightenment and PHP debugging bliss.

It's a sixteen step process, but don't let that scare you off - it's made up of lots of little steps like "make a phpinfo() page" and "download IntelliJ IDEA". The rest is actually setting up a new PHP project, dropping in a breakpoint and mapping the scripts to run on your local machine's WAMP install.

How about creating a PHP code validator? Got this idea by looking at tokenizer and reflection extensions. I doubt I will find the time to work on this myself but then someone else might be interested to pick it up. From user's point of view there will be a form made of a large textarea box and a single file upload input. One could paste code snippet on that textarea or upload a ZIP'ed source code archive (or a single .php file) for validation.

His proposed result would show a list of "Required Extensions", PHP versions, E_STRICT compatibility and possibly total lines of code in the project. He points out a few issues that might pop up in writing such a tool such as the requirement for it to be able to use the tokenizer extension itself (a sort of catch-22 since it's not always installed).

My brother Mark has been doing a long term project based on Magento doing a lot of custom work on top of it, and has told me many points, both good and bad, about it.

According to Michael and Mark, speed of the application is a big hindrance. They also mention two points that could help make an ecommerce system so much easier to integrate into the "blogosphere" - publishing a blog feed of some of the user feedback about orders/products/etc and accept trackbacks from an external blog post reviewing the products.

There's five different ideas that he presents:

• CSS files named without any link with controller names
• CSS with the same controller name
• CSS file with the same name of controller, but only if CSS file exists
• one CSS file for each method of controller
• a CSS file for each method of controller, a little bit more organized