Articles in the ‘Releases’ Category

MooTools 1.1 Upgrade Helper (beta)

Written By Moo Tools, on Thursday, December 31st 2009, 3:03pm

Users wishing to upgrade any large site from MooTools 1.1 to 1.2 can sometimes find it difficult. The API for 1.2 changed quite a bit, so without help upgrading your code can be fraught with danger.

Our solution is an upgrade helper that will allow you to replace your old MooTools 1.1 code with 1.2 code by logging deprecated methods to the console and telling you what needs to be changed.

The upgrade helper also attempts to automatically convert 1.1 calls to 1.2 calls. However, this helper is not really meant to be a compatibility script so much as a script designed to help you migrate your code. In almost all cases methods that have been deprecated or have had their API altered will provide feedback to the console when they are called. Ideally, developers will put this script into their environment with MooTools 1.2, use their application and change all the calls that throw warnings, then remove the upgrade helper from their environment.

Using the Upgrade Helper

You can download the upgrade helper on the MooTools Download Page along with current build of MooTools built for it. This companion library has all the functionality found in MooTools 1.1 (Drag, Accordion, etc. - some of these plugins moved out of MooTools Core and into MooTools More in 1.2).

Simply replace MooTools 1.1 with MooTools 1.2, include the upgrade helper, then include your site’s code. Browse your site with a browser that provides a console API (we recommend Firefox with Firebug) and take note of the warnings thrown (note, you can adjust the logging; see the readme). Address these in your code base until you cannot find any more, then remove the upgrade helper. You have now an upgraded website, and you can use the plugins in the Forge!

If you still have warnings after you have finished converting your code, have a look at the documentation for 1.1 and 1.2 and also the source code in the upgrade helper. Most changes are simple, but may require a change of arguments. There are a few breaking changes but in the vast majority of cases these should not affect you. A complete list of the changes between 1.1 and 1.2 can be found in the readme of the github upgrade-helper repository.

Feedback, Help, and Resources

The upgrade helper is being released as a beta for now. We’ve written and run tests against the browsers we support but the real world usage of MooTools will be the real test. As such, we hope that you, the MooTools community, will help us polish this script, by letting us know what features on your sites don’t work. Bugs can be filed using the github issues for the repository.

Arguably, this is something we should have provided long ago. Going forward, we’ve pledged to make all releases 100% backwards compatible for all documented methods and features.

Should you require any guidance or assistance, you can, as always, find us in the #mootools IRC channel or post in the MooTools Google Group.

Last of all, massive thanks to Nathan White and David Isaacson, for their early work on this. In the last few weeks the MooTools Dev team has spent a lot of time making and testing this upgrade helper, but these guys kicked this off with their contributions and they are most appreciated.

MooTools Depender - A Build Tool for MooTools JavaScript Libraries

Written By Aaron Newton, on Monday, November 9th 2009, 2:10pm

As mentioned in the new features in MooTools More in, there’s a new plugin called Depender which uses MooTools dependency mappings to allow you to lazy load additional scripts on the fly based on what you need. Rather than list every single file you depend on, you just list the features you want to use and it computes all the specific files needed and each of the files that they need (and so on), excludes the files you already have, and then injects the remaining scripts into the document, providing a callback.

Unfortunately this method is rather slow. The JavaScript plugin must inject each individual script in the dependency list and all these requests can only go as fast as your browser can make them. As a companion to this plugin, we have also authored a stand alone server side application.

New Server-Side Depender

The new server-side depender companion app ships in two forms: a PHP version and a Django version. They each have their own positives and negatives. The PHP version ships with a web-based interface — a builder you can use to check off the things you want in your download (similar to what you see on On the other hand, the Django version is faster. The Django app caches everything to memory but the PHP version caches results to disk.

Depending on your needs, you can also use these server-side applications to lazy load chunks of functionality on the fly. This obviously requires your application to talk directly to the server when it needs more code. These apps aren’t designed for enterprise scale.

The server side applications are available on github. We still consider the state of this project to be beta, but we want to get the tools into your hands now. If you have any feedback or find any bugs, we want to hear about it. Check out the documentation to see how it all works, including the Depender Client(docs), which gives you this nifty interface:

            scripts: ['DatePicker', 'Logger'], //array or single string for one item
            callback: function() {
                    //your code that needs DatePicker and Logger
    //later, you need to load more dependencies...
            scripts: 'Fx.Reveal', //array or single string for one item
            callback: function(){
                    //if, for some reason, Fx.Reveal is available already,
                    //then this function will execute immediately, otherwise it will
                    //wait for the requirements to load

Libraries that you download with Depender will all have a standard header that looks something like this:

    //MooTools, <>, My Object Oriented (JavaScript) Tools. Copyright (c) 2006-2009 Valerio Proietti, <>, MIT Style License.
    //MooTools More, <>. Copyright (c) 2006-2009 Aaron Newton <>, Valerio Proietti <> & the MooTools team <>, MIT Style License.
    //Contents: Core, Browser, Array, Function, Number, String, Hash, Event, Class, Class.Extras, Element, Element.Event, Element.Style, Element.Dimensions, Selectors, DomReady, JSON, Cookie, Swiff, Fx, Fx.CSS, Fx.Tween, Fx.Morph, Fx.Transitions, Request, Request.HTML, Request.JSON, More, Element.Shortcuts, Element.Measure, Fx.Reveal
    //This lib:

This header includes, among other things, a manifest of the contents of the file and a url that can be used to retrieve it again. This is especially useful if you want to come and download the file again for the latest version.

The builder on does not use Depender yet but we will deploy it there soon. You can see it live on the Clientcide builder.

MooTools 1.2.3 Released

Written By David Walsh, on Friday, June 19th 2009, 4:32pm

Today we give you what will likely be the final release of the MooTools Core before the jump to 2.0. While MooTools 1.2.3 is primarily a bug-fixing release, MooTools 1.2.3 also introduces an important new feature: Framework compatibility mode.

The value in making this change is allowing developers to use more than one framework within a page (which is NOT something we recommend or endorse, but we recognize this is not always under the developer’s control). Not relying on the dollar function prevents the need for jQuery.noConflict() when using jQuery and MooTools together, for example. If no other framework is detected, however, $ will be assigned to MooTools. This means that all of your current MooTools code WILL NOT break. It does, however, mean that if you want to use MooTools and jQuery together (without using jQuery’s noConflict mode), instead of using $ in your MooTools code, you’ll have to use

If you want your MooTools plugins to be cross-framework compatible, you’ll have to replace all the instances of $ with change only applies if you’re using more than one framework on your pages. If all you use is MooTools, nothing will change for you. Look forward to more details about Framework compatibility mode in a future post.

MooTools Core & More Updates

While we encourage you to browse LightHouse and the histories for MooTools Core and MooTools More to get the most detailed list of changes, the following significant updates were committed in MooTools 1.2.3:


  • Element: MooTools compatibility mode: the $ function is only defined if no pre-existing $ function is found. If an existing $ function is found, you can use
  • Element: changed internal instances of $ to
  • Core: fix for server-side MS JScript 5.x; makes MooTools more friendly for server side programming
  • Class: Class doesn’t require Browser, removed from scripts.json
  • Element: Fixes for set/get Property
  • Element.Dimensions: fix for webkit body.scrollTop inconsistency, getBoundingClientRect used whenever possible (not just for Trident), renaming element.position to element.setPosition; adding docs for the method; alias is included in-line for compatibility
  • Hash: Hash extend no longer uses the window if no arguments supplied
  • Request: clearing Request readystate before calling success or failure;
  • Selectors: Added :enabled pseudoselector, was in the Docs but not implemented.
  • Docs: Fixed docs headers for first-child, last-child, and only-child.
  • Internal: UnitTester test suite is now a git submodule
  • Numerous small fixes, speed improvements, documentation tweaks, etc.


  • Per the change in -core, $ is no longer used (uses instead)
  • Element.Measure: trying cssText solution for Element.expose (again).
  • Element.Forms: swapping feature detection for browser support per
  • Date: Massive refactoring of Date.js and Date.Extras.js
  • Drag.Move: Fixing drag with grid issues
  • IframeShim: altering zindex assignment in IframeShim to better ensure that it’s always underneath the shimmed element, updating Iframeshim’s empty document creation; fixes https issues in IE6
  • FormValidator: reworking formvalidator scroll-to logic to be a little more efficient
  • OverText: preventing overtext from focusing on inputs except when they are interacted with (so OverText.update() does not focus an input);now stops polling when elements are hidden (when polling is enabled)
  • Fx.Scroll: adding scrollIntoView method - scrolls an element so that it is completely visible; if below the view, scrolls down until it is at the bottom of the screen, if above, scrolls up until it is at the top.
  • JSONP: was calling (the deprecated) this.request instead of this.send during retries
  • URI: Adding set(‘data’, obj) to set
  • Assets: adding error callback for Assets.images
  • Tips: removing dependency for Element.Measure for Tips; updating CSS class name in OverText
  • Numerous small fixes, speed improvements, documentation tweaks, etc.

MooTools 2.0 is on the Horizon

As mentioned above, 1.2.3 is likely the last update for MooTools 1.2. MooTools 2.0 will introduce numerous performance improvements and new features. We want to stress that MooTools 2.0 will feature 100% compatibility with MooTools 1.2.x.

Thank You!

Thank you for the bug fixes, feature requests, and support during MooTools’ 1.* lifetime. You, the MooTools community, have helped make this framework better with every bug found and question asked on the forum. We look forward to releasing MooTools 2.0 this summer and getting feedback from everyone in this awesome community.

MooTools More

Written By Aaron Newton, on Tuesday, May 5th 2009, 5:51pm

Today we’re releasing a small update to MooTools More that address a few bugs and minor feature requests that cropped up after the initial launch. Briefly, these are the things changed since

  • Removed debug statement that enabled IframeShim in all browsers by default
  • Fixed a few docs typos
  • Removed UTF-8 charset signature on String.QueryString and URI.Relative
  • Assets.image now have an onError option and handle image load failure more gracefully
  • FormValidator.Inline had issues displaying some of it’s validators when input values changed
  • OverText now allows you to specify the element type for the label test (defaults to “label”)
  • Fixed an issue with addRequests in Request.Queue; the arguments were reversed (addQueue still worked fine though)

None of these changes should affect your usage of the class, except, possibly, the change to OverText, as the element it previously created for the labels was a div. If you styled these with css and referenced the tag name, you’ll either need to update your css reference or pass in element: “div” as an option when you invoke the class.

MooTools 1.2.2 and the New MooTools More

Written By Valerio Proietti, on Thursday, April 23rd 2009, 7:53pm

Today we’re releasing two goodies for you: MooTools 1.2.2 and the new MooTools More (


MooTools 1.2.2 is a mainly a bug fix release but it also includes an almost entirely new Class.js. The reasoning behind this is that the old Class.js didn’t play nicely with some advanced usages of this.parent() present in the new MooTools-More. We already had the script ready and tested in the MooTools 2.0 branch so we simply “backported” it to 1.2.2. Other than providing the parent fixes, the new Class also features a much more robust inheritance model, especially when dealing with objects.

For example, the objects you implement now in a class are merged if an object with the same name is found in the class prototype:

var Animal = new Class({
    options: {
        color: 'brown',
        says: 'hissss'

Animal.implement('options', {says: 'meow'});

// Animal.prototype.options is now {says: 'meow', color: 'brown'};

This is especially useful when overriding default options in classes, such as Request.

Another object-oriented feature we introduced is that now sub-objects are actually inherited Parent-to-Child. If you implement a new option in Animal, then Cat, which is a subclass of Animal, will get the new option as well, and so will every instance already existing. An example:

var Cat = new Class({
    Extends: Animal

var kitty = new Cat();

Animal.implement('options', {nu: 'one'}); == 'one' //true == 'one' //true

This obviously also applies to methods.

Additional changes to the MooTools Core in 1.2.2 are mostly minor bug fixes.


One of the new features of MooTools-More, since the last RC, is that it is now possible access the previous state of overwritten methods of classes through Class.refractor. An example:

var Cat = new Class({
    energy: 0,
        eat: function(){

Cat = Class.refactor(Cat, {
    eat: function(){
        this.previous(); //energy++!
        alert("this cat has " + + " energy");

This functionality allows users to integrate seamlessly with existing classes, and add to existing methods without the need to subclass.

We’re considering some way to make this behavior more generic for a possible inclusion in MooTools-Core 2.0.

The first RC of MooTools-More produced a lot of feedback and contributions that we’ve integrated as we prepared for our full release. Following this full release of the new MooTools More plugins, we’ll begin adding new features quickly and regularly with what we hope will be biweekly releases.