Pádraic Brady has posted a 20 point list that wants to help you prevent cross-site scripting (XSS) issues in your applications.

Summarising knowledge has as much value as writing a 200 page treatise on a topic, so here is a list of 20 brief points you should bear in mind when battling Cross-Site Scripting (XSS) in PHP. Minus my usual book length brain fart . Chances are good that ignoring or acting contrary to any one of these will lead to a potential XSS vulnerability. It's not necessarily a complete list - if you think something needs to be added, let everyone know in the comments.

His tips include things like:

• Never pass data from untrusted origins into output without either escaping or sanitising it.
• Remember that anything not explicitly defined in source code has an untrusted origin.
• Always include ENT_QUOTES, ENT_SUBSTITUTE and a valid character encoding when calling htmlspecialchars().
• Use rawurlencode() to escape strings being inserted into URLs and then HTML escape the entire URL.
• Validate all complete URLs if constructed from untrusted data.
• Remember that HTMLPurifier is the only HTML sanitiser worth using.
• Ensure that cookies which must only be transmitted over HTTPS are marked Secure.

He points out that XSS is still one of the most "popular" (and easy to exploit) attack methods out there, so keep these tips in mind when writing up your code.

Thomas Buck has put together what he calls "Tom's PHP Commandments" (nine of them) that developers should follow when developing applications with the language. Among his suggestions are things like:

• ALWAYS do the simplest thing that will work
• NEVER trust anything that comes from the user
• NEVER use include for controlling logic
• NEVER create a file of useful functions, even if it's called helpers.php

There's also been some discussion about this list over on Reddit - you can comment on it over there if you agree/disagree with some of his points.

In this latest post to his site Rob Allen talks some about application structure and the different kinds of objects he uses in his applications.

I currently use a very simple set of core objects within my model layer: entities, mappers and service objects. [...] I dislike the phrase "service object" as the word "service" means so many things to so many people. I haven't heard a better phrase yet that everyone understands though.

He defines each of the types of objects to help make the separation clearer. Here they are in brief:

• Entities are objects that represent something in my business logic.
• Mappers know how to save and load an entity from the data store.
• Service objects provide the API that the rest of the application uses.

Some of the comments on the post relate his choices to use in Zend Framework v2-based applications, noting that there are some base components you can extend to create these kinds of objects.

In this new post to his site Vinícius Krolow shares some tips he thinks will help to make your PHP code more readable in the long run.

What about code readability, from my point of view is one of the most important thing in the code. Who writes code that is easy to read, writes good code. Probably reading code is where you spent most part of your time, and not only your code, probably code of your team mates, or maybe code from the open source community, so write code that is simple and is easy to understand it's really important.

His tips (seven of them) are:

• Comment before write your code (DocBlock)
• Return frequently, Return early
• Break, Continue
• Code Standard / Name conventions
• Throw Exception
• Comment often, but not write stupid comments
• Methods can be always smaller than they are

It's a little difficult to read as the English isn't the speaker's native tongue, but it gets the point across. He also recommends reading this if you'd like more information about writing better OOP code that's easier to read.

In this new post to PHPMaster.com today Alexander Cogneau takes a look at what's different in version four (v4) of the Laravel framework as it has changed from version three.

Laravel is a PHP framework which uses the MVC pattern. Of course, there are many such projects and I'm not going to compare Laravel with other frameworks in this article. Instead, I'm going to share with you what's new in the newest version of Laravel - Laravel 4.

There's a list of things that have changed (each with a summary of what they are):

• Decoupled Components
• Creating a "Normal" Project
• Routes
• Better Code through Testing
• The Container and Its Bindings
• Improved CLI
• New Database Features
• Using Stand-Alone Components

Rob Allen, in his Zend Framework 2 development, has come up with a list of suggestions about the use of modules in your applications, mainly relating to the structure of the files inside of them.

I've been working on a Zend Framework 2 module within a larger project that doesn't have that many PHP class files. Specifically, it has a controller, a mapper, an entity, a service and a form. As a result, the traditional Zend Framework 2 directory structure for the Account module looks [overly complicated]. That's a lot of directories for not many files! As a result, I decided to flatten it to [something simpler].

He includes both the "before" and "after" directory structures and continues on with two more suggestions - the removal of the top level "Account" folder inside of "src/" and, finally, removing "src/" all together with a slight modification to the autoloading. With a simpler module, though, something like this might make it easier to maintain and "follow" later down the road.

The latest issue of the Web & PHP Magazine has been released - Issue 8 - The Power of Design. Articles in this latest issue include:

• Todd Lombardo on user context
• Stefan Priebsch on data and persistence
• Patrick Allaert about data structures
• June Henriksen on the human side of programming

You can find out more about this issue (and go download your free copy) on the Web & PHP site. There's also seven previous issues, all free for download (PDF format)!

On the Smashing Magazine site today they've posted a list of powerful CLI tools that every developer should at least know about to help make their lives easier - six of them ranging from SSH tunnels to HTTP testing.

Good tools are invaluable in figuring out where problems lie, and can also help to prevent problems from occurring in the first place, or just help you to be more efficient in general. Command line tools are particularly useful because they lend themselves well to automation and scripting, where they can be combined and reused in all sorts of different ways. Here we cover six particularly powerful and versatile tools which can help make your life a little bit easier.

The tools they mention are all things you'd install on a unix-based system:

• Curl
• Ngrep (network packet searching)
• Netcat (to work with network connections)
• Sshuttle (SSH tunneling)
• Siege (HTTP benchmarking)
• Mitmproxy (capturing proxy, both HTTP and HTTPS)

On PHPMaster.com there's a new tutorial showing you how to work with files and directories through your PHP applications.

In this article I'll talk about a common task you might have experienced while developing a PHP application: listing files and directories. I'll discuss several basic and advanced solutions, each having its pros and cons. First I'll present three approaches that use some very basic PHP functions and then progress to more robust ones which make use of SPL Iterators.

The solutions they look at are the built-in functions like glob and readdir/opendir as well as SPL iterators up for the task - FilesystemIterator, RecursiveDirectoryIterator and GlobIterator. Code samples are included in the post, showing how to use each method to get and list the files. A few helpful hints are also included to finish off the tutorial (mostly about "tricks" to using the functions effectively).

Josh Adell has a new post today looking at the "powerful combination" of using traits and interfaces in PHP applications. He shows how, despite traits not implementing the interface directly, they can be used to make other classes adhere to them simply by "using" them.

If you're not using interfaces in PHP, you are missing out on a powerful object-oriented programming feature. An interface defines how to interact with a class. By defining an interface and then implementing it, you can guarantee a "contract" for consumers of a class. Interfaces can be used across unrelated classes. And they become even more useful when combined with the new traits feature in PHP 5.4.

He illustrates with a package shipping example and uses an "Addressable" Interface to define the structure for both a Company and Users class. He includes code showing how to implement it in a more traditional "implements" way in a class, but also shows an interesting way to achieve the same thing with traits. Having a trait that follows the interface makes it easy to have a class adhere to the interface just by including the trait (or "using" it).