Earlier this week I wrote about Mozilla’s response to my answers to their web developer survey and how they were building strong ties and customer loyalty through communication. On top of taking the time to respond, the information they provided was very helpful. Below are excerpts from the e-mail I received from Alix Franquet in response to my feedback, as well as some comments about the items discussed.

You mentioned you had trouble finding versions of Firefox to test, so I wanted to point you to a couple of places that might help:

It’s true. One of the biggest frustrations I had with trying to help test pre-release versions of Mozilla products was actually finding them. Alix’s response addresses this concern.

- The Mozilla developer news blog will also have the latest release announcements and point to the download page and release notes: https://developer.mozilla.org/devnews/

This looks like a good place to start for anyone wanting to stay updated on the latest releases of Mozilla products, as well as a good source of information for developers and testers.

- The nightly builds of Firefox are available at: http://nightly.mozilla.org/

This is for those wanting to help test the latest bleeding edge version of Firefox.

- When a beta is released, it’s available at http://www.mozilla.com/firefox/all-beta.html – since there’s no beta right now you are redirected to the latest release (Fx 3.6) but this will change once we have a Fx 3.7 beta 1 out.

If you’re feeling a little less adventurous, but still want to test early releases, you can take the current beta version of Firefox for a spin. This will allow you to preview some of the new features and improvements, but in an environment that’s more stable and predictable than the nightly releases.

- Thunderbird’s early releases are available here: http://www.mozillamessaging.com/en-US/thunderbird/early_releases/

The go-to place for Thunderbird’s early releases, including everything from alpha versions to release candidates. What I like about this page is that it provides a one-stop shop for all of your Thunderbird testing needs. Want an alpha release? They’ve got it. Only interested in beta versions? They’re there too. You don’t have to hunt down each release at a different location.

- If you’re interested in joining our test community, you should check out http://quality.mozilla.org/ – we’re always looking for new people to be involved! You will get announcement for new releases and test days.

And finally, this is where to go for anyone interested in joining the test community. There you can do everything from test products to submit your own code. Or, for the less hands-on but equally important tasks, help find and reproduce bugs or analyze crash data and user feedback.

Thank you so much for your feedback, we’re going to work on making it easier to find the different versions.

Alix ends her response by saying they’re planning to make finding this information even easier in the future. I think that’s absolutely critical to garnering user feedback and important test data. If users can more easily find the test versions they’re looking for, it’ll be all the easier for Mozilla to receive the feedback that’s crucial to improving their products.

This is just a quick tip, but ever since discovering it I use it constantly. A lot of developers use PHP’s print_r() function to display human-readable information about a variable, which makes it great for debugging arrays and objects (among other things) very quickly. However, you have to wrap the output in <pre></pre> tags otherwise it gets spit out in a jumbled mess and doesn’t display nicely.

echo '<pre>';
print_r($foo);
echo '</pre>';

That works just fine, but you can shorten it up by passing true to print_r()‘s second parameter, the $return flag, and mixing it in with your echo statements. What this does is tells print_r() to return the human-readable variable data instead of printing it to the screen right away.

echo '<pre>' . print_r($foo, true) . '</pre>';

Earth-shattering code breakthrough? Absolutely (not). However, it does turn three lines of code into one and makes it quicker (for me, anyway) to write quick debugging statements and move them around easier.

As an added bonus, you can “queue up” a bunch of print_r()‘s by capturing their output in a variable and then echo’ing it just once.

$debug = print_r($foo, true);
$debug .= print_r($bar, true);
echo '<pre>' . $debug . '</pre>';

Voila, shorter debugging statements that are easier to work with.

Customization is key, so when I had spent a considerable amount of time trying to disable editor resizing in CKEditor and kept coming up blank, it started to get frustrating. Here we have a pretty solid editor coupled with a pretty solid lack of documentation – reminds me a bit of Magento! To their credit, it’s still extremely new and they are working on documentation for it. That aside, I managed to stumble across a post on their forum that led me in the right direction.

Open up ckeditor/config.js and put the following code in there.

CKEDITOR.editorConfig = function( config )
{
	config.resize_enabled = false;
};

Ultimately, I was aiming to disable only horizontal resizing but that feature’s not available yet (can’t seem to find the forum post where a dev suggested they might implement it). The whole reason I wanted to disable resizing in the first place is because as soon as you would start to drag the resize handle, the editor width would shoot out and you couldn’t make it any smaller. Turns out it’s another somewhat hidden config setting forcing the resize width to a minimum amount.

If you want to keep resizing enabled but adjust the minimum width, use the following code instead.

CKEDITOR.editorConfig = function( config )
{
	// Sizes are in pixels
	config.resize_minWidth = 550;
	// config.resize_maxWidth = 700;
	// config.resize_minHeight = 200;
	// config.resize_maxHeight = 500;
};

As you’ll notice, there is also a setting for resize_maxWidth, along with similar ones for controlling the height. Any config settings you put in this file will be the new defaults for all editor instances, and once you know some of the things you can change here, you can really streamline the setup of new editor instances throughout your application.