For the Symfony2 users out there, a site has been started to help you run through a checklist and prepare your application for deployment, the Symfony2 Checklist. It's a set of things you can cross off by clicking on them to ensure you're set to go when the right time comes.

The list includes things like:

• Check the production server
• Customize error pages
• Use Doctrine cache
• Configure Monolog
• Protect your forms

It's a good base list to start with, but there's other things to consider (some more app-specific) that need to be thought through before deploying. If you have others you'd like to see added, you can always fork the repository and submit a pull request with the updates.

In this recent post to his site Greg Freeman share some things to check for when you think your PHP site (any kind, even something like WordPress) might have been compromised.

A friend of mine recently had their site compromised, they were running an older version of IP.Board that is vulnerable to a local file inclusion vulnerability. This post won't be about IP.Board or any specific php code, it will show you how to locate potential malicious php code hosted on your servers and how to fix it. Finally I will give a brief explanation on what attacker's are uploading to compromised sites.

Among the things he recommends are tips like:

• Check your Access Logs
• Finding Recently Modified PHP Files
• Finding obfuscated code
• Always search your writable upload directories for executable code
• Check .htaccess Files if you use Apache

You can find the descriptions for each of these (and some others to watch out for) in the full post.

Smashing Magazine has a great new article that's a must read for anyone looking to start up an open source project with some guidelines to follow as you get things set up.

At Velocity 2011, Nicole Sullivan and I introduced CSS Lint, the first code-quality tool for CSS. We had spent the previous two weeks coding like crazy, trying to create an application that was both useful for end users and easy to modify. Neither of us had any experience launching an open-source project like this, and we learned a lot through the process.

The article reads like a checklist of things you'll need to consider as you create your project - things like:

• Determining what your goals are
• Choosing a license
• Code structure and organization
• Documentation

There's also a few other suggestions that may or may not be useful depending on the project like "use a mailing list" or "use version numbers" but they're all good ideas. Even if you're already working with an open source project, this is a good overview and could give you food for thought on things you might have overlooked.

Matthias Noback has a new post today sharing some of his experiences working with Open Source software, specifically as it relates to this dealings with a "Symfony-friendly environment".

These days, good PHP object-oriented libraries are all around and easily available. To me, it is actually thrilling to be part of this flourishing community, while working with Symfony2 and blogging about the Framework, the Components and their neighbors (like Silex). [...] Still, to me, contributing felt like too big a step to take right now. Until a few weeks ago, when I was looking for something I needed (a PHP client for the Microsoft Translator API) and could not find a decent solution. I decided to make it myself, and share it online.

He shares his "checklist" of steps he followed to get the library up and working (less about the library and more about the process):

• Write the code
• Initialize a Git repository
• Add a composer.json file
• Add unit tests
• Make it open source and developer friendly
• Push your code to GitHub
• Register your project at packagist.org
• Register the Packagist Service Hook
• Versioning
• Continuous integration using Travis CI

He also suggests that, at least at the outset, you skip some of your tests that might rely on external data sources/resources (so the build can start as green on Travis) then coming back and refactoring to mock things out correctly. It might look like an intimidating list for a beginner, but it's a great process to follow to have a robust, effective development/deployment process.

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.