Jose Anthony has post together a great list of tips you can use when performing a PHP code review. You can also use it when preparing for a review to keep things going as smooth as possible.

I love to do code reviews because it give me chance to see how other people write code and improve mine also. I have seen many people who are afraid of doing code review. Which made think of creating a code review checklist for php. Please note this is not full checklist for code review and following all the conditions in this will not end up in a great code. But following this will end up in code that can be maintained by others in the later stage of code development.

Some of the suggestions he has in the list include:

• Always try to initialize the variable before using that in a function.
• Never ever mix the php code and template (view). In ideal condition a view should not contain any logic.
• In the case of a system crash never ever put up the error information that expose the internal behavior of the system.
• Never allow bad code with some good comments
• Always have an eye on the recursive functions.

On SK89Q.com there's a recent post with a long list of security tips you can follow to help ensure some of the most common security issues are taken care of on your site.

There was a recent question about a PHP security checklist on a forum I frequent, and I've decided to write my own comprehensive checklist to fill the void. There's something for everyone but the security expert. In fact, you might find an issue that you never thought about. Securing PHP web applications would be a better title for this article.

Tips shared in the post include:

• Have strong passwords be sure that your "password recovery questions" are not too obvious.
• Be aware that you can initiate a request from something as simple as telnet, so that means that all incoming data can be forged.
• Don't forget that inputted numbers can be very large, very small, zero, or negative. You don't want to deposit a negative number of credits!
• The mime type/file type in the $_FILES array is provided by the user and can contain any value. Not only can the provided mime type be spoofed, it could also just be wrong or be overly generic. (Conclusion: The field is useless.)
• Do extensive path checks to make sure you do not serve a non-uploaded file.
• Never use user input directly in a pathname.
• Be aware that a malicious user can sniff for packets to get a user's password. The only real solution to this problem is to use SSL.

There's lots more where this came from - a few pages of tips at least. There's not much in the way of actual code to show you how to integrate the tips into your application, but it's still a very useful list. You can also grab the full list as a downloadable cheat sheet [pdf].

On Till's blog today, there's a checklist of sorts to help make moving a Magento-based online store over to another server.

Frequently, you do client work and if you are fortunate enough, you can setup a development environment on your own server or your laptop (or whatever), tinker with the files, and templates, and so on '" until it's all done. And whenever you are done, it's time to move files. Sounds easy? It sort of is!

His small checklist only contains three main steps - change the configuration file if need be, check the permissions on certain directories to make sure they can be accessed/written to by the web server, and updating the base URLs for the new domain name/location.

Till has come up with a method for keeping track of the things needed to correctly build out a server, a checklist package written in PHP.

For a couple weeks now we kept on saying that we need a checklist of what we need on a server in order to make the site run - now since we setup the neato bonito cluster last week the checklist all of the sudden had a higher priority and I took an hour or so to create that last night.

The code loops through the loaded extensions (get_loaded_extensions) and runs a shell_exec on a directory to see if the requirements are met.

In conjection with the release of PEAR 1.4.9 as previously mentioned, Greg Beaver wants to clarify some things when it comes to setting up a PEAR channel in "the official way" and with the correct pakcages.

There has been quite a bit of confusion recently due to the best resource for setting up a channel being located on Toby's blog, and now being quite a few versions out of date. First of all, let it be known that the PEAR_Server package located at pear.chiaraquartet.net has been superseded by the Chiara_PEAR_Server package at pear.chiaraquartet.net.

The rest of the post is concerned with his checklist and step-by-step guide to getting and setting up the needed software. It's the whole process, right down to creating a nice frontend for the users and how to test your channel to ensure it's properly set up.

It's definitely the definitive guide to setting up a PEAR channel correctly.