Zoom: The Magento Full-Page Cache goes Open Source

Download Latest version from GitHub

Support the Zoom FPC Project:

Since releasing the Zoom Full-Page Cache for Magento, things have been exciting around here, but we are only getting started! From this point forward, Magento no longer needs to be saddled with the reputation of being a slow resource-hog. And no longer will businesses need special hosting providers or rooms full of servers to run a competent store. Zoom is now open-source at GitHub and will be coming to Magento Connect soon.

We jumped into this thinking that  a small, quick project like the Zoom FPC woud be a great initial offering of our commercial services. But after some long thought and recent interaction with many community members, we've considered the following:

• Magento really needs ZoomI have experienced everything from 4/10th of a second to 4 second page loads with Magento CE on highly optimized systems. This expansive code base--weighed down with magic gets, heavy-abstraction and resource-insensitive design--can buckle under its own weight, rendering it useless in many scenarios. The Zoom Full-Page Cache really does unlock a large portion of Magento's potential by delivering the pages as fast as static content. Implemented properly, your webserver becomes your bottle-neck and Magento Community performs like enterprise level software.
• There are already enough commercial products fixing basic deficienciesI love open source software as much as the next guy, but I am apprehensive of the Open Source as Crack business model. Lipstick and potential can lure a "customer" into adopting a free platform, only to find themselves in a corner faced with a decision: "should I cough up thousands for an actual usable product or should I migrate yet again?" Many free products are simply unsupported demos, and entire industries exists to "fix" these products for distressed users--I don't want Ezapps to be a part of that model.
  
  At this point, Zoom will never have a commercial version. What you see is what you get. When I have time, I will fix bugs found in the system. I will also accept community offered bug-fixes and incorporate them into the main code.
  
  With that said, I have been very busy altering Zoom to work with highly customized Magento stores, as well as expanding it. If you need any help in that area, contact us and we will be happy to provide a quote.
• This allows us focus on more important offeringsThe Zoom FPC was never originally on our radar (most of our active projects are platform independent). It was a quick idea, rush-coded in the midnight hours for Magento mass-consumption. Open-sourcing this product lets us get back to the basics. If the response to Zoom continues to be positive, we will probably be bringing these other projects out commercially.

So, to finish up, if you download Zoom and find it useful, please realize that we are a small company that will only thrive if you:

• Tell your friends
• Report bugs and contribute
• Support the project

If you need installation help or any custom work done, such as expanding Zoom's hole-punching to custom blocks or resolving conflicts with other custom modules, please let us know. Thanks!

Zoom Full-Page Cache and Customized Magento, Part 1

Resolving Conflicts

The most common question I have been asked about the Zoom Full-Page Cache is: will it work with my custom Magento modules? In most cases Zoom has proven to be versatile, but if you have a module installed that is trying to override the same core block that Zoom is, there is some leg-work required.

When these conflicts appear either 1) a block will not be punched, or 2) it will be punched, but it will lack the functionality of your custom module. In one scenario, your block is being used, while in the other, the Zoom block has been chosen by Magento. There is also the case of a model being in conflict, and that is resolved in a similar way to what I describe below.

When there is a conflict, you will normally have a class that looks like:

class Custom_Module_Block_Template_Links extends Mage_Page_Block_Template_Links

And a Zoom class that looks like:

class Ezapps_Zoom_Block_Wrapper_Links extends Mage_Page_Block_Template_Links

If you do not feel comfortable altering your store source, or even the source of your extensions, you may not want to proceed without professional help. When in doubt, please feel free to contact us and we can provide a quote. And remember, always backup your source and database before making evasive changes.

Method 1: Using your block

Zoom overrides very little core functionality, and is normally just trying to wrap the HTML content to mark a "hole" (an area to remove and fill in later with dynamic content). So the easy answer is to simply copy the Zoom source into your custom class.

First, copy the following variables/code from the Zoom block to yours. You may have to merge the two versions if they share methods:

private $_key = 'holename';
private $_cache_tag = true;

public function __construct() {  // COPY ZOOM CLASS CODE  }

public function _afterToHtml($html) {  

    // ONLY CALL ZOOM FROM CUSTOM MODULE IF IT EXISTS AND IS ACTIVE
    $modules = (array)Mage::getConfig()->getNode('modules')->children();
    if (array_key_exists('Ezapps_Zoom', $modules) && 
        $modules['Ezapps_Zoom']->is('active') ) {

           // COPY ZOOM CLASS CODE

    } else return parent::_afterToHtml($html);
}

public function setCacheTag($status) {  // COPY ZOOM CLASS CODE  }

public function getCacheTag() {  // COPY ZOOM CLASS CODE  }

Next, remove the rewrite statement for this block in Zoom's "config.xml". Your custom block will now create its own hole.

Method 2: Using Zoom's Block

You may not want to alter your own custom block, because this may prevent future upgrades of that module. A more brute-force method of over-ridding a previously over-ridden core block is as follows...

First, change:

class Ezapps_Zoom_Block_Wrapper_Links extends Mage_Page_Block_Template_Links

To:

// PATH TO CONFLICTING BLOCK
require_once("Custom/Module/Block/Template/Links.php");

class Ezapps_Zoom_Block_Wrapper_Links extends Custom_Module_Block_Template_Links

Next, remove the rewrite statement for this block in the custom module's "config.xml". The Zoom block will inherit the other blocks changes, and continue to create the hole.

Method 3: Give EZAPPS a Call

By now, we have a plethora of experience when it comes to identifying and resolving these conflicts, and we have made Zoom cache very difficult content without dramatic effort. What might be hours for you could be a few minutes for us (though we have faced some very customized Magento stores that required a great deal of effort). We have some popular extensions already modified to play nice with the Zoom Full-Page Cache.

With that, I hope enough people in the community learned how to resolve conflicts when you have two modules competing for the same core Magento block. This principle also applies to any situation where this may occur (even outside the usage of Zoom).

We have some very exciting news on the horizon and soon I will also cover how to hole-punch custom modules that are not in the original Zoom package--so stay tuned.