The Laravel News site has posted the latest part of their "Building a Laravel Translation Package" series focusing on a pre-launch checklist of items to get in place before it's finally released.

In the last part of the series, we finished up building the Laravel Translation package. With this completed, we are ready to start thinking about releasing the it to the world. However, before we do, there are few important steps we need to take.

The post covers some of the final non-code items to take care of:

• Good documentation
• Defining contribution guidelines
• Providing issue templates for easier reporting of bugs/issues by others
• Selecting a license
• Setting up continuous integration for running tests, checking code style, etc.

Each item in the list includes a brief summary of what's involved and, for some, links to other resources and tools that can help get it accomplished.

On the SenseDeep Security site Michael O'Brien has posted a web developer security checklist you can use as a starting place towards securing your application (and developing secure applications from the start).

Developing secure, robust web applications in the cloud is hard, very hard. If you think it is easy, you are either a higher form of life or you have a painful awakening ahead of you.

[...] After you review the checklist below, acknowledge that you are skipping many of these critical security issues. At the very minimum, be honest with your potential users and let them know that you don’t have a complete product yet and are offering a prototype without full security. This checklist is simple, and by no means complete. It is a list of some of the more important issues you should consider when creating a web application.

He breaks it down into different sections with items to check off for each:

• Database integration and data storage
• Development environments and security scanning
• Authentication
• Denial of Service protection
• Securing the Web Traffic
• APIs
• Validation (input and whitelisting)
• Cloud service and Infrastructure configurations
• General Operations and Testing

He ends with two points that are easy to forget when developing any application: determining what you're protecting against (threat modeling) and having a practiced security plan in place. Remember, checklists are a good place to start but by checking off each item it doesn't mean you're 100% secure.

In part one of a new series on the SitePoint PHP blog Bruno Skvorc looks at the right way to start a PHP package using a set of guidelines that have evolved recently in well-structured, well-tested PHP packages.

In recent years, good standards for PHP package design have popped up, in no small part due to Composer, Packagist, The League and, most recently, The Checklist. Putting all these in a practical list we can follow here, but avoiding any tight coupling with The League (since our package won’t be submitted there – it’s specifically made for a third party API provider and as such very limited in context).

The list of rules includes topics like having a license selected, using PSR-4 autoloading and having in-depth code comments. Bruno uses these as a foundation and starts in on the creation of a package. He uses the PHP League skeleton structure to create the files and folders for a basic package. From there he updates the contents with details for his Diffbot example and installing other needed software libraries. The rest of the post is broken up into the two remaining steps and examples under each: sticking with the PSR-2 guidelines and planning for the structure of the package.

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.