PHP_CodeSniffer 1.3.0 development plan

A while ago, I was contacted by Gabriele Santini, lead PHP architect for SQLI in Paris. Gabriele had some great ideas to make PHP_CodeSniffer more powerful and had already started developing a wrapper for PHP_CodeSniffer to implement many of them. I finally got the time to look through this wrapper recently and I was impressed with what I saw, but couldn't change PHP_CodeSniffer in a way that would make it easy for Gabriele to maintain the wrapper without duplicating a lot of code.

But these were such great ideas that I had to act on them. So we've now teamed up to implement the changes into PHP_CodeSniffer itself. Work has already started (the first commits went in today) and a development plan has been created.

You can read about the features on the Squiz Labs blog post.

New PHP_CodeSniffer blog

Squiz Labs (the R&D arm of Squiz, and the company that I work for) launched their new blog last week, developed in our new MySource Mini CMS. This blog covers the CMS products we produce, but also has a dedicated section for PHP_CodeSniffer.

I'll be blogging about PHP_CodeSniffer over there, so subscribe to that dedicated PHP_CodeSniffer RSS feed if you want to keep up-to-date with what is happening on the project.

The RSS feed URL is: http://feeds.feedburner.com/SquizLabsBlog-PHP_CodeSniffer
The PHP_CodeSniffer blog URL is: http://www.squizlabs.com/php-codesniffer

Not much there right now, but I did at least remember to post a notification about the 1.2.1 release even though I forgot to post about it here.

Running the MySource Mini VM with VirtualBox

If you don't have access to VMWare player to give the MySource Mini virtual machine image a try, you can use the free VirtualBox player instead. VirtualBox has the ability to use the HDD image from VMWare without the need to have VMWare installed. You do need to set a couple of options though, which I'll run you through.

The first thing you need to do is download VirtualBox. Make sure you have the latest version (I'm using 3.0.10) as I've read that older versions may not have all the options we need.

Now you want to create a new virtual machine. Give it a name (MySource Mini is fine) and it will ask you what type of OS it is. You want to pick Linux, Debian (64 bit).


You'll need to pick how much memory you want to give it. I gave mine 512MB but it doesn't really matter as you can change this later.

The next bit is the virtual hard disk. You want to use an existing hard disk. Click the icon to launch the Virtual Media Manager. Click Add and then locate the MySource Mini folder that was extracted from the MySource Mini download. Select the file MySource Mini.vmdk and then use this as hard disk for your VM.


Now you can finish creating your VM. It will appear in the VM list once it has been created, but you need to configure a few more things before you can start it up.

Select the VM and click Settings. Go to System and make sure Enable IO APIC is selected.


Now go to Storage, select Enable Additional Controller and make sure SATA (AHCI) is selected from the drop-down. In the Attachments section at the bottom, click IDE Primiary Master and select SATA Port 0 instead.


You may need to fiddle with your Network settings as well. I had to use Bridged networking for some reason, but I haven't looked into why NAT was not working for me.

If everything works, your VM will boot and entering ifconfig eth0 should show you a valid IP address you can connect to. Now you can follow the VM Quick Start guide and have your MySource Mini system up and running in a few minutes.

MySource Mini now free to download

The big news (for me) at the MySource Matrix International User Conference (MMIUC) this year was that MySource Mini can now be downloaded for free as a virtual machine image. You'll need VMWare player to run the image, but you are also free to convert it to another format if you want.

In addition, Squiz showed its commitment to open source by announcing that MySource Mini will be released under the GPL and will have a public SVN repository. We're in the process of getting this ready and we'll have it done in a couple of weeks.

Sticking with our goal of keeping everything about MySource Mini simple, the virtual machine is easy to install and you can subscribe to the automatic up-to-date system to have it upgrade itself. A personal subscription is only $250 a year and when you take a look what has been added in just 6 months, it's great value.

I showed a demonstration at the MMIUC of the new features added since the MySource Mini launch in April this year. The main features I showed were:
- multi-site support
- embedded videos and automatic conversion to FLV files
- embedded and lightbox-style image galleries
- track changes functionality built right into the inline WYSIWYG editor
- improvements to the help system for new users
- an integrated bug-tracker based on Bugzilla

I've been saying how good MySource Mini is for a while and how its powerful functionality is made simple through great user interfaces. But now you don't have to take my word for it. Grab the VM and have a play around yourself.

Product site: http://mini.squiz.net
Download page: http://mini.squiz.net/download

Why check JavaScript and CSS files with PHP_CodeSniffer?

Websites and browser-based application interfaces are getting richer. This isn't new, but it's certainly increasing and is now a much higher expectation of popular sites and software products. This means more JavaScript and more CSS and it often means much more advanced JavaScript and CSS than PHP developers are used to.

PHP may power the guts of your application, but the interface has moved on. It's not just a heap of hard-coded HTML output via your PHP template engine with a few JS and CSS files included. It's now a proper grown-up rich user interface with all sorts of trickery and fanciness. And PHP developers are having to add JavaScript and CSS to their everyday toolkit.

The days of JavaScript development and CSS styling being a nice change for a PHP developer are gone. It's quite likely you are doing more JavaScript and CSS work than PHP for much of the time. You know PHP and it's easy to implement the basic functionality you need quite quickly. But the interface takes longer. Everyone sees your interface code and it has to run in a range of web browsers.

You'll probably spend quite a lot of time working on interfaces before having to head back into PHP to make some functional changes. And this is exactly where coding standards come in handy. You are necessarily having to change between different development languages and all PHP developers on your team need to be able to produce good quality JavaScript and CSS, no just a select few.

PHP_CodeSniffer has support for checking JavaScript and CSS files in addition to PHP source code. It does this by using custom tokenizers to make JavaScript code look as close as possible to PHP code to the sniffs. CSS code looks different but sniffs are written in the same way as PHP and JavaScript sniffs and can listen for special token types that PHP_CodeSniffer creates.

So here is the main benefit of using a PHP_CodeSniffer standard that checks JavaScript and CSS files; consistency.

Just like PHP code, developers tend to write JavaScript and CSS in whatever style they are used to. I believe consistency is much more of a problem with these file types because developers can be lacking knowledge, reverting to copy/paste jobs from the published code examples, or possibly just focusing so much on this new code that they forget that their code will need to be maintained by others. And then there is the fact that the JavaScript engines are pretty forgiving and you can seemingly write code however you please.

PHP developers are really embracing quality assurance processes like unit testing and coding standards. Don't leave the basics behind when you leave PHP behind to work on an interface. Keep your code clean and consistent and follow a coding standard so your whole team can read and maintain your code more easily.

But consistency is not limited to code created by multiple developers in a single language. A good coding standard can actually make your PHP and JavaScript code look similar, providing consistency between languages. This makes it much easier to switch between PHP and JavaScript code, either for writing code or just reading it during debugging, and is equally as good for fast switching throughout the day or long stretches spent coding in a single language.

A nice side-effect of using a good coding standard that has support for JavaScript and CSS checking is that it can find errors in your code that can cause browser compatibility issues. This is something PHP developers don't think a lot about when doing day-to-day PHP development, but it is something vitally important when working on interfaces.

So what do I recommend? PHP_CodeSniffer of course, but potentially a more strict and comprehensive standard than the default PEAR standard. The PEAR standard does not check JavaScript and CSS files and doesn't included sniffs that hook into the 3rd-party JavaScript lint tools. The Squiz standard does all this and might be a good option for you if you are deciding on a standard to use. It is very strict (121 sniffs as opposed to 26 for the PEAR standard) but I do believe it helps produce very good code and it is extremely well maintained. Or you can always build a custom coding standard as well, pulling sniffs from the Squiz standard as required.

Whatever path looks best for you, I encourage you to make a JavaScript and CSS coding standard part of your development kit. You can use PHP_CodeSniffer to enforce it in the same way you check your PHP files, so there is really no excuse any more.

PHP_CodeSniffer 1.2.0 released

It's been just over 13 months since the last stable release of PHP_CodeSniffer, but today I've finally released version 1.2.0 and it's packed with features and fixes.

Some of the highlights:
- support for checking CSS files
- the ability to tell PHP_CodeSniffer to ignore parts of your code
- writing any report to a file
- a new emacs report format
- integration with JSLint
- the ability to specify a list of sniffs on the command line
- support for multi-file sniffs
- full support for the new PEAR coding standard
- 35 new sniffs to use in your own standards
- 27 bug fixes

Thanks to everyone who tested alpha and beta releases over the last 12 months and a special thanks to everyone who took the time to submit bug reports and contribute features.

You can view the full changelog and download the release on the package download page.

An easy way to leak memory using DirectoryIterator

I've been trying to track down a memory leak while running the PHP_CodeSniffer unit tests after being told the PEAR-wide test suite was running out during my run. My own testing showed the unit tests started at 11MB of memory used and ballooned out to about 56MB, even with no error messages being generated.

I already do a bit of cleanup to save memory (unset()ing some member vars mostly) and I tried cleaning just about everything else out, but memory usage didn't drop. I don't have any circular references, so I had nothing obvious to try.

After a bit of playing, I found the problem; a DirectoryIterator.

My code looked a bit like this:

$di = new RecursiveIteratorIterator(new RecursiveDirectoryIterator($dir));
foreach ($di as $file) {
    $basename = basename($file, '.php');
    if (substr($basename, -5) !== 'Sniff') {
        continue;
    }
}

The $file variable is a DirectoryIterator item. I was passing it into the basename() function and relying on the fact that PHP would cast it to a string (the file name).

I changed the code to grab the file name first and then pass it into the basename() function, like this:

$di = new RecursiveIteratorIterator(new RecursiveDirectoryIterator($dir));
foreach ($di as $file) {
    $fileName = $file->getFilename();
    $basename = basename($fileName, '.php');
    if (substr($basename, -5) !== 'Sniff') {
        continue;
    }
}

So now the tests only use 16MB of memory; a healthy saving of 40MB. There is probably a bit more that can be saved by calling this code less during testing, but this was a good (and easy) result regardless.