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.

PHP_CodeSniffer 1.2.0RC3 released

I've just uploaded version 1.2.0RC3 of PHP_CodeSniffer. RC3 is a feature release rather than a bug fix release because there were a few nifty features (like error message suppression) that I wanted to get in before the next stable.

This is the last planned release candidate before 1.2.0 stable.

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

Suppress error and warning messages in PHP_CodeSniffer

Just over 13 months ago, I had a feature request submitted for PHP_CodeSniffer to allow developers to annotate their code with comments that tell PHP_CodeSniffer to ignore some lines. At the time, I remember thinking "This is a hack!", but I've changed my mind. PHP_CodeSniffer version 1.2.0 will have error message suppression comment tags.

You use them like so:

$var = TRUE;
// @codingStandardsIgnoreStart
if ($var === true) {
    echo "true that";
}
// @codingStandardsIgnoreEnd

If you use the Squiz coding standard that comes bundled with PHP_CodeSniffer, it will complain about pretty much everything and tell you you can't have "true" in lowercase and that echo'd string can't be in double quotes.

Without the new suppression tags in place, you get this:

FILE: /Users/gsherwood/PHP_CodeSniffer/temp.php
---------------------------------------------------------------
FOUND 3 ERROR(S) AND 0 WARNING(S) AFFECTING 3 LINE(S)
---------------------------------------------------------------
 2 | ERROR | Missing file doc comment
 4 | ERROR | TRUE, FALSE and NULL must be uppercase; expected
   |       | "TRUE" but found "true"
 5 | ERROR | String "true that" does not require double quotes;
   |       | use single quotes instead
---------------------------------------------------------------

With them in place, you get this:

FILE: /Users/gsherwood/PHP_CodeSniffer/temp.php
---------------------------------------------------------------
FOUND 1 ERROR(S) AND 0 WARNING(S) AFFECTING 1 LINE(S)
---------------------------------------------------------------
 2 | ERROR | Missing file doc comment
---------------------------------------------------------------

Too easy. Sorry it took so long.

Please don't be tempted to wrap your entire file in these tags. The Squiz standard will still find ways to yell at you and you're not fooling anyone.

Grab the code from CVS now or wait for the next release, which will be whenever I get my act together.

Managing videos in MySource Mini

In the next couple of weeks, we'll be releasing a MySource Mini update that contains much more advanced video management functionality than the first release. In typical MySource Mini style, it's simple and sexy while still being very powerful. And I've got some screenshots of the feature in development as a bit of a teaser.

Our end goal for this development was to allow users to upload any common video format and be able to embed it in their websites in a way that made it available to the highest number of site visitors. Like most video sharing websites, we decided on a Flash-based player and we will be creating our own player so we can skin it in the way users want.

We also had to take editing, thumbnails and versioning into account so movies fit seamlessly into the MySource Mini graphical environment.

Uploading a movie is as easy as uploading an image.


Once you've uploaded your movie, it is converted to an FLV file automatically so we can play it using our flash player. The original file is retained so you can link to your high quality MOV/AVI/etc. if you'd like. We also extract thumbnails from the movie so you can select the one that fits the best without having to create your own.


In the future, we'll be adding an option that allows you to replace this thumbnail with one you have created yourself, but we want to keep things simple to start with.

Now that your movie is loaded into the system, you will be able to embed it into any page using the Viper WYSIWYG editor. It will be the same process as inserting an image, but we are still building this WYSIWYG plugin so I can't show you any screens of it yet.

Versioning is great feature of MySource Mini and movies fit nicely into the whole system. Just like with pages, you can flick through different versions of your movie by looking at quick-loading images. Even if you've uploaded a large movie, this montage-based preview allows you to quickly scan through versions without having to download each one. When you've found the one you like, you can download it as normal.


The movie shown above is an old preview of the MySource Mini caching system, so the whole movie looks similar. I've also got a more interesting image for an old versioning system preview movie.


For more information about MySource Mini, see the MySource Mini website, or follow @mysourcemini on Twitter.

PHP_CodeSniffer 1.2.0RC2 released

I've just uploaded the a new PHP_CodeSniffer release. RC2 is a bug-fix only release, although it does contain one tiny change to the test suite so it can be integrated more easily run by external testing scripts.

Please download and review. There are currently no bugs in the PHP_CodeSniffer bug tracker, so this will become the stable 1.2.0 unless any show-stoppers are found.

For those reporting problems with the SVN pre-commit hook on this blog, I've tested everything (including adding directories) and it is all working fine. If you have any problems, please report a bug using the PEAR bug tracker (no bug reports in comments please).

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

Missing/Back in action

It's been about 2 months since my last post. A lot has been happening and I've been really busy. If I had posted over the last couple of months, the posts would have covered:

MySource Mini, MySource Mini and more MySource Mini. I've been so busy getting this product ready for launch that I've been almost completely consumed by it. It's a terrific product though and I'm very proud of we we've achieved. We had the launch last week (a great review here), had a great team dinner at Sydney Tower on the weekend to celebrate and are now busily preparing units for delivery. Along with that, I'm also working hard on the MySource Mini product website (running on a Mini of course) and getting the news out via Twitter.

Sadly, I've neglected PHP_CodeSniffer over the last few months as a result. The bug reports started piling up but I'm happy to report I'm getting on top of them now. I think there is currently one outstanding at the moment, which isn't too bad. Downloads of PHP_CodeSniffer have been through the roof over the last two months so I'll be putting out an RC2 soon for people to try out before the next stable release.

I'll start posting again soon. In the meantime, follow me on Twitter.

PHP_CodeSniffer 1.2.0RC1 released

I was just looking at the download stats for PHP_CodeSniffer version 1.2.0alpha1. Normally, my alpha releases get a very small number of downloads due to most users not allowing alpha state packages to be installed via PEAR (fair enough). But the 1.2.0 alpha got over 300 downloads. That's a great figure and a few bugs were fixed from that testing, but there is a very good reason why there were so many downloads - I released it nearly 4 months ago.

To be honest, besides fixing the odd bug, I haven't been working on PHP_CodeSniffer lately. I'm very busy working on the MySource Mini and our coding standard seems to be nearing completion, so there is less work to be done there as well. But 1.2.0 is a good release with some great reporting improvements, so it's about time I released a beta version.

This release candidate is essentially a bug-fix only release, but please test it if you can so I can push it stable as soon as possible and start working on new features again.

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

Seven Things - Tagged by Sebastian and Manuel

I've been tagged for this meme by Sebastian Bergmann and Manuel Pichler, so I can hardly ignore it now!

Seven things you may not know about me:

• I didn't even know how to code a table in HTML when I started as a web developer at Squiz.
• I didn't pick the name PHP_CodeSniffer. It was suggested by Pierre-Alain Joye (http://blog.thepimp.net) when I submitted "Snoopy" to PEAR.
• I'm slightly addicted to WoW, but I swear it's not my fault and my wife is addicted too, so it's not that bad.
• I've never been to a PHP conference or user group. I just can't ever seem to find the time, especially now with a 1 year old.
• I'm the main cook in the house, and I love it!
• I love cats and dogs and have had 5 dogs and 4 cats as pets so far.
• I don't have a Facebook account even though several people have tried to sign me up. One less thing to be addicted to.

And the seven lucky people I have picked to do this next are:

• Till Klampaeckel for being a PHP_CodeSniffer early adopter
• Pierre-Alain Joye for helping me get into the wonder that is PEAR
• Laurent Laville for helping me get PHP_CodeSniffer working on Windows
• Scott Kim because he codes PHP all day long and needs something to add to his blog
• Richard Hulse for convincing me Git is a great VCS, even if I haven't done anything about it
• Nathan de Vries because he's a smart guy with and without PHP
• Nic Hubbard for making his first contribution to a PHP open source project just recently

And here are the rules of the game:

• Link your original tagger(s), and list these rules on your blog.
• Share seven facts about yourself in the post - some random, some wierd.
• Tag seven people at the end of your post by leaving their names and the links to their blogs.
• Let them know they've been tagged by leaving a comment on their blogs and/or Twitter.

PHPUnit training at Squiz

Sebastian Bergmann was in Sydney last week and I took the opportunity to have him come in and do a day of PHPUnit training for the developers at Squiz. We also went through continuous integration software like phpUnderControl and Bamboo.

It was great to finally meet Sebastian and learn a lot about the tools we will be using in MySource4 to ensure the quality of our product.

If you are thinking of some in-house PHP training, Sebastian is great tutor on all things testing and comes pre-loaded with some funny and informative stories about his travels and PHP development in general.

PHP_CodeSniffer reporting improvements

Spurred on by some feature requests and at least one annoying colleague (you know who you are), I've made some fairly good improvements to the way PHP_CodeSniffer reports the errors and warnings it finds. I've added support for the concept of error sources, allowing you to see which sniff generated an error and also filter out the messages for that sniff.

The XML, CSV and CheckStyle report formats all now include a source attribute in their output. This will allow continuous integration platforms to call PHP_CodeSniffer and produce a report of the most common errors rather than just display a list of all errors or the number of errors for each file.

You can also expose this information in the full and summary reports, although it is off by default to avoid clutter. Use the new command line argument -s to show sources in these reports. Instead of something like this:

FILE: /home/squiz/PHP_CodeSniffer/temp.php
--------------------------------------------------------------------------------
FOUND 6 ERROR(S) AND 0 WARNING(S) AFFECTING 5 LINE(S)
--------------------------------------------------------------------------------
 2 | ERROR | Missing file doc comment
 3 | ERROR | Object operator not indented correctly; expected 4 spaces but
   |       | found 0
 3 | ERROR | Object operator must be at the start of the line, not the end
 4 | ERROR | TRUE, FALSE and NULL must be lowercase; expected "true" but found
   |       | "TRUE"
 6 | ERROR | Object operator not indented correctly; expected 4 spaces but
   |       | found 1
 9 | ERROR | TRUE, FALSE and NULL must be lowercase; expected "false" but found
   |       | "FALSE"
--------------------------------------------------------------------------------

You get this:

FILE: /home/squiz/PHP_CodeSniffer/temp.php
--------------------------------------------------------------------------------
FOUND 6 ERROR(S) AND 0 WARNING(S) AFFECTING 5 LINE(S)
--------------------------------------------------------------------------------
 2 | ERROR | Missing file doc comment (PEAR.Commenting.FileComment)
 3 | ERROR | Object operator not indented correctly; expected 4 spaces but
   |       | found 0 (PEAR.WhiteSpace.ObjectOperatorIndent)
 3 | ERROR | Object operator must be at the start of the line, not the end
   |       | (PEAR.WhiteSpace.ObjectOperatorIndent)
 4 | ERROR | TRUE, FALSE and NULL must be lowercase; expected "true" but found
   |       | "TRUE" (Generic.PHP.LowerCaseConstant)
 6 | ERROR | Object operator not indented correctly; expected 4 spaces but
   |       | found 1 (PEAR.WhiteSpace.ObjectOperatorIndent)
 9 | ERROR | TRUE, FALSE and NULL must be lowercase; expected "false" but found
   |       | "FALSE" (Generic.PHP.LowerCaseConstant)
--------------------------------------------------------------------------------

There is also a totally new report format that shows a summary of your error sources. You use the command line argument --report=source to print a report like this:

PHP CODE SNIFFER VIOLATION SOURCE SUMMARY
------------------------------------------------------------
STANDARD   CATEGORY      SNIFF                         COUNT
------------------------------------------------------------
PEAR       White space   Object operator indent        3
Generic    PHP           Lower case constant           2
PEAR       Commenting    File comment                  1
------------------------------------------------------------
A TOTAL OF 6 SNIFF VIOLATION(S) WERE FOUND IN 3 SOURCE(S)
------------------------------------------------------------

You can also get it to use official source names using the -s command line argument:

PHP CODE SNIFFER VIOLATION SOURCE SUMMARY
------------------------------------------------------------
SOURCE                                                 COUNT
------------------------------------------------------------
PEAR.WhiteSpace.ObjectOperatorIndent                   3
Generic.PHP.LowerCaseConstant                          2
PEAR.Commenting.FileComment                            1
------------------------------------------------------------
A TOTAL OF 6 SNIFF VIOLATION(S) WERE FOUND IN 3 SOURCE(S)
------------------------------------------------------------

The idea with these source IDs is that you can then use them to filter your (potentially) long list of error messages and target a particular rule that you want to fix all in one go. So in this report, we have 3 errors generated from PEAR.WhiteSpace.ObjectOperatorIndent. To find out what they are, add the command line argument --sniffs=PEAR.WhiteSpace.ObjectOperatorIndent to get this:

FILE: /home/squiz/PHP_CodeSniffer/temp.php
--------------------------------------------------------------------------------
FOUND 3 ERROR(S) AND 0 WARNING(S) AFFECTING 2 LINE(S)
--------------------------------------------------------------------------------
 3 | ERROR | Object operator not indented correctly; expected 4 spaces but
   |       | found 0
 3 | ERROR | Object operator must be at the start of the line, not the end
 6 | ERROR | Object operator not indented correctly; expected 4 spaces but
   |       | found 1
--------------------------------------------------------------------------------

Another related feature that was added is the ability to write the report output to a file in addition to writing it to the screen. This solves the problem where PHP_CodeSniffer comes across some code it cannot parse and throws PHP notices before XML output, creating invalid XML. Writing to a file is easy; just use the --report-file=filename command line argument.

All these features are currently in CVS and will be released in 1.2.0a1 very soon.

PHP_CodeSniffer and JSLint

PHP_CodeSniffer has had integration with JavaScript Lint for a while, but I recently found out that the excellent online JavaScript verifier, JSLint, can be run from the command line using Rhino.

I've just committed the JSLint sniff into the Squiz standard under the Debug category. The sniff requires you to have jslint.js on your server and rhino installed on the same machine as PHP_CodeSniffer and you need to tell PHP_CodeSniffer where to find it.

$ phpcs --config-set jslint_path /path/to/jslint.js
$ phpcs --config-set rhino_path /path/to/rhino
$ phpcs --standard=squiz /path/to/file.js

Like JavaScript Lint, not all errors and warnings need fixing, so all messages reported by jslint.js are warnings within PHP_CodeSniffer and can be hidden easily.

Interface design; an interative process

I was looking back at some old mockups and screenshots of the MySource Mini today and it is really amazing to see how the product's interface has progressed over the last 12 months or so. It's interesting to see how elements of the design changed, and while not all these mockups were built, all contributed something to the design we have today.

In this post, I'm going to show you the mockups we produced of the Settings/Administration interface. This is where you configure things like designs and caching for individual assets and for the site as a whole.

This first mockup was implemented in early 2007 and represents the first interface of the MySource Mini. We went for a desktop feel with large icons, but it gave us very little space to fit the actual editing interface. We still love large icons, and the concept of icons to represent different systems remains today.


It was soon clear we needed more space for the editing interfaces, so we went full screen. That meant sacrificing the large icons we loved so much and moving to a toolbar along the top, a concept that remains today.


The start of 2008 saw us bring on a dedicated interface designer who began reworking the main concepts of the interface. At the time, the inline content editing interface was progressing well and we wanted to bring the context you get from that interface into the settings screens. So we scaled back from full screen a little so you could see the page underneath.

This mockup was done in January 2008 and implemented soon after. It was the first time we really tried to bring that context into the rest of the interface, which we have now done using thumbnails of the page. Notice the side menu, which is almost identical to the current multi-add wizard interface.


One thing that always bothered us with this temporary interface was how dark it was. We didn't want to go for the desktop-inspired background image from the earlier mockups, but we wanted something lighter to contrast well with the black MySource Mini toolbar.

This mockup was done in March 2008 and was not implemented. It was used in most of our mockups for quite a while and was growing on us. It was light and looked fresh. It didn't have large icons, but the chunky menu buttons made up for it.


There was one thing lacking though; context. We needed somewhere to put our thumbnail and asset information.

This next mockup was very close to being the final interface. It was designed in May 2008 and implemented, although all the system icons were the same at the time. It is the first time the blue info box made an appearance, which gave us room to add a thumbnail and asset information.

In this mockup, an administration screen is shown, so the blue box does not contain asset information, but you should be able to see how we jumped to our final interface design from here.


In August 2008, we changed our minds again. The grey bar at the top was looking too much like a second toolbar and didn't feel polished enough. The whole interface was looking a bit too much like an old desktop application and we wanted something fresh.

We decided to lighten everything up and add the large icons back in. We had heaps of room for the content editing area, so we could go very web 2.0 with large menus and bright colours.


I've promised the team that I wont change my mind again, so this is the interface we will be using in the final MySource Mini release. I'm sure you'll agree it is a big improvement over our original interface and I hope you've enjoyed this small insight into our interface design process.

MySource Mini demonstration

Update: After being featured on Ajaxian, Vimeo decided they don't want to host my videos any more and deleted my account without warning. I've re-posted the 30 min demo below, but be warned - it is 117MB!

I recorded the 30 minute demonstration of the MySource Mini that I gave at the MySource Matrix International User Conference a couple of weeks ago. I've posted the demonstration online so everyone can check out this new product from Squiz, even if you couldn't make it to beautiful Coogee for the conference this year.

PHP_CodeSniffer == CSS_CodeSniffer?

Earlier this year, I added support for tokenizing JavaScript files to PHP_CodeSniffer so developers could ensure their JS files also conform to their coding standards. With new products like the MySource Mini using such rich JS interfaces, PHP developers are having to move away from traditional server-side coding improve their client-side coding skills. Having JS support in PHP_CodeSniffer was a move to recognise this and we are now using it very successfully within Squiz to check for formatting and performance errors.

The next natural step was to add support for checking CSS files. These same PHP developers are having to write large amounts of CSS these days and, in my experience, CSS files tend to be fairly messy when a large number of developers are working on them. To counter this, I've added a basic CSS tokenizer to PHP_CodeSniffer and the Squiz coding standard now enforces formatting standards such as indentation and spacing around colons.

Sniffs can be written to improve the performance of both PHP and JS code and the same is true for CSS files, although it works a little differently. One of the sniffs in the Squiz standard ensures that shorthand notation is used to define CSS colours where possible (e.g., #F0F instead of #FF00FF). This helps to ensure developers focus on keeping the size of CSS files down, even though we will certainly minimise the size before deployment. I think PHP_CodeSniffer helps to remind developers of these performance issues each time they run the checker, which can only be a good thing.

I've committed the CSS tokenizing code to CVS, so you can grab it directly from there or wait until the 1.2.0a1 release in the next few weeks.