Testing PHP_CodeSniffer without installing

PHP_CodeSniffer has always contained extensive unit tests for all code sniffs, but the testing structure required the package to be installed so that tests could be placed into an expected location. The tests also use PHP_CodeSniffer itself, and it requires the package to be installed so that the require statements that rely on the PEAR include path would work correctly. So basically, neither PHP_CodeSniffer or the unit tests could be run without installing the package first.

PHP_CodeSniffer is not a library, it is a development tool, so this shouldn't matter. However, PEAR has recently pushed to get repository-wide code coverage stats for unit testing. All unit tests must now run correctly when the package is checked-out from CVS and without being installed.

To solve the problem, I turned to the newly proposed PEAR2 standards, which are being hotly debated at the moment on pear-dev.

To be honest, I wasn't sure about those standards when I first read them. I could see the merit for some libraries, but it was hard to see how those changes would make PHP_CodeSniffer better. I still don't think they are going to make PHP_CodeSniffer easier to use, but they have certainly made it easier to develop and test for.

The change that I made was to remove all my require_once() statements and replace them with class_exists() and interface_exists() calls with the optional second argument for autoloading. The PHP_CodeSniffer class now has an autoload method that includes the class files from different locations depending on if the package is installed or not.

The benefit of doing this is that the AllTests.php file that starts the unit testing off only needs to find the CodeSniffer.php file and its own test files. Once CodeSniffer.php is included, all other files are included automatically. Couple this change with a few other minor tweaks to remove some hard-coded assumptions about file paths and lengths, and you've got a unit test suite that runs from CVS. As an added benefit, modifying a single include inside the phpcs script allows you to run PHP_CodeSniffer itself without installing the package.

Index: scripts/phpcs
===============================================
RCS file: /repository/pear/PHP_CodeSniffer/scripts/phpcs,v
retrieving revision 1.16
diff -r1.16 phpcs
20c20
< require_once 'PHP/CodeSniffer.php';
---
> require_once '../CodeSniffer.php';

While these changes were made primarily for the PEAR unit testing system, they have also meant that I can stop installing the package to test every change I make. That is making development easier for me, and that's a good thing.

What is inline content editing?

Update: Squiz decided to tackle this problem and we've created our own truly inline WYSIWYG editor called Viper. You can find out more, and watch a video of it in action, on the MySource Mini inline editing feature page.

A lot of products claim to have inline content editing, but it's obvious that everyone has their own interpretation of that phrase. Inline content editing seems to come in six main flavors, although I've yet to see a true inline content editing interface.

Stand-alone WYSIWYG editing

This style of content editing displays a stand-alone WYSIWYG editor embedded into an editing interface. The editing interface and the site frontend have no common elements. The WYSIWYG editor takes the styles from the site's style sheets and displays them inside the WYSIWYG editor. This allows the page author to see their content as it would be displayed on the page, but they cannot see how the content will look when the other page elements are placed around it. Generally, a preview is provided to allow the author to switch between editing and previewing the content.

The MySource Matrix administration interface uses this style of inline editing. The content editing screen and the preview screen are accessed separately, but the site design's styles are shown while editing in the WYSIWYG editor.

The advantage of this style of editing is that the author has a large area in which to edit content. The disadvantage is that the author cannot see how their content will flow inside the page without saving their work and switching to a preview.

Embedded WYSIWYG editing

This style of content editing is similar to the stand-alone WYSIWYG editor, but this style places the content items around the WYSIWYG editor so the author has an idea of how the content will fit with the overall style of the page. This inline preview is limited though. For complex pages with multiple content areas, the WYSIWYG editor itself changes the page layout and makes the inline preview less accurate. The author still requires a preview mode to confirm that the page looks the same as it does during editing.

The MySource Matrix simple edit interface uses this style of inline editing. The editor is the same as that in the administration interface, but the size is now the same as the content area and the site's design is shown around the editor. IP.Board also uses embedded WYSIWYG editing in their new quick edit forum post editing interface.

The advantage of this style of editing is that the author can see quickly how the content of the page will look within the site's design. The disadvantage is that the editing area is often smaller, resized to fit within the body area of the page. Some editors provide a full-screen mode to get around this size limitation, but that transforms the editing interface into a stand-alone editor, with all the disadvantages that brings.

Popup WYSIWYG editing

This style of content editing was made famous by RedDot. Content areas within a page preview are marked as editable using an icon that floats over the content or some other obvious style. Clicking that icon displays a stand-alone WYSIWYG editing interface. Once the content is saved, the new content is written back to the page preview.

For a good demonstration of this style of content editing, take a look at this inline editing demo video for Community Server. The first part of the video shows true inline content editing with text boxes only, not an uncommon thing to see, but the second part shows inline editing of complex page elements like HTML areas.

The advantage of this style of editing is that the preview is always accurate. The disadvantage is that content is still edited using a stand-alone editing interface, not allowing the author to see a true preview of the content until they have completed editing.

It is worth noting that some editing interfaces take this style a bit further and write back to the page preview in real-time. This allows you to switch to the preview without saving or to have the page preview and editing interface side-by-side. Certainly, this is an improvement, but it does require multiple monitors to really make use of this feature and is does require the author to switch focus frequently while editing.

Whole page WYSIWYG editing

To get around the problem of having a preview mode and an edit mode, this style of editing uses a WYSIWYG editor to edit the entire contents of the page, including the site design and all page elements. The author gets inline editing and a very accurate preview.

The advantages are obvious, but the disadvantages outweigh them in my opinion. When the entire page is editable, there is no way to lock parts of the page and stop the author from editing them. For anything but the most simple of sites, this is not an acceptable situation. Sure, you can build components into the WYSIWYG editor to stop the author from editing some content in WYSIWYG mode, but switching to the common "HTML source" mode allows the author to change all parts of the page.

Some editors get around the disadvantages by removing the source mode, or providing their own source mode that locks part of the page from being edited. Most editors that do this are written in either Flash or Java so the developers have full control over the editing interface.

If you ask me, a full screen custom WYSIWYG editor is just an application running inside the browser and not the inline content editing interface of a content management system. As new features need to be added to the CMS, they need to be built into the full-screen WYSIWYG editor. So what you end up with is just a CMS written in Flash or a Java applet.

Inline WYSIWYG editing

This style of content editing is similar to embedded WYSIWYG editing except that the editor is made to be almost invisible. By removing the borders of the editor and resizing it dynamically as the content within it changes, the author is given an almost perfect editing and preview mix. The editing feels inline and the preview looks accurate. Better yet, the author does not have to shift focus between editing and preview modes.

So is this perfect? It is very close, but not quite what I would call true inline content editing. The content generated by the WYSIWYG editor still needs to be saved back to the content repository and cleaned to remove browser-specific code that is added by the browser's editable region. Using a non-JavaScript WYSIWYG editor, such as Flash or Java, can get around this but then adds the requirement of a browser plugin.

True inline WYSIWYG editing

True inline WYSIWYG editing combines the advanced preview mode of popup WYSIWYG editing interfaces while maintaining the clean lines of inline WYSIWYG editing interfaces. For me, true inline content editing needs to be done with a JavaScript WYSIWYG editor, but not one that simply uses the browser's own editable region. A true inline WYSIWYG editor needs to alter the source of the page as the author makes changes to the content. By editing the source directly, and not just inside an editable iFrame, the author gets a truly accurate preview while editing content without having to switch to a preview mode.

This is really the holy grail of content editing interfaces, bringing inline HTML editing programs like Dreamweaver into the browser. So what's the catch? You'll be very hard pressed to find a JavaScript WYSIWYG editor that can edit the source of a page directly without requiring some sort of custom browser plugin or having strict browser requirements, like IE or Firefox support only. Mozile, the Mozilla Inline Editor, is about as close as you can get at the moment, but that editor is far from complete and doesn't work in IE.

PHP_CodeSniffer 0.7.0 (beta) released

Version 0.7.0 of PHP_CodeSniffer was released today. It wasn't intentional, but it has been almost two months since the last release. Consequently, it has the largest changelog of any release so far, including a couple of backwards compatibility breaks for those writing their own coding standards. There are also ten new sniffs for you to use in your own standards, or as examples for writing your own sniffs.

The most important feature added was the auto-detection of line endings, previous discussed here. This feature allows for PHP_CodeSniffer to be used correctly for projects that don't use Unix newline characters.

This release also has also seen the unit test suite grow to 100 tests, a nice milestone.

You can download the new release, and view the changelog, on the download page.