Delorum Commerce is proud to announce that TinyBrick has left the nest and begun to fly. You can now find everything TinyBrick including product information, product updates, detailed online documentation, and new releases, all at TinyBrick.com. You should also check out the new TinyBrick Blog.

For everything else ecommerce related, Delorum Commerce will still be here. We have some pretty amazing projects running in the background that you’ll definitely want to hear about. So check back. We’ll be posting soon.

Now even if the same page has multiple currencies, when you change session-set magento currency to another besides the default, Lightspeed and SpeedBooster re-cache the new currency on that page as if it were new.

If you already purchased Lightspeed or SpeedBooster, upgrading is free-of-charge. These newest versions can be downloaded from the “Account” section of store.delorumcommerce.com. Just click on the Download tab of the Lightspeed or SpeedBooster module. After you’ve downloaded the new version (2.9.2 – Lightspeed or 2.3 – SpeedBooster), update your installation with a single command from the terminal: ./pear upgrade /path/to/downloaded/PackageName.tar.gz

This multi-currency support is the manifestation of a newer functionality we’re considering (but haven’t implemented yet): session-aware caching. The idea is that when a session variable is set (like language, currency, or even a custom variable you choose) even if a URL remains the same, lightspeed would cache an entirely new page. This could open up new doors for developers and new possibilities for customized content based on certain session variables. The only question is: Would you use this on your site?

Leave a comment. Let us know.

After a quick 5-minute installation, TinyBrick’s Magento Tweet Button automatically adds a Tweet button to all your critical pages. This includes your CMS (including home page), category, and product pages–enabling your customers to directly comment on all of your products and even your entire site. (We have  a demo setup here)

Also, if you have a store or company Twitter account, the default Twitter message that Tweet Button populates for users automatically attributes any Tweet back to your store Twitter account. This can quickly provide a growing crowd of customers who follow your tweets and make product announcements, sales, and other promotions social and communicative directly to your customers.

We’re offering this product at an competitive price of only $35. More features for this product are sure to come.

What’s going on?

First, understand from a high-level that Lightspeed caches entire pages. It’s like taking a picture of a group at a family reunion. Instead of having to get the family back together every time you want to show that particular page (or see that group of people), you just bring up the photo you took. With Lightspeed, instead of loading PHP, running through Magento, and making DB calls to generate a page, Apache simply returns the static HTML generated for that page when it was first cached (Or that picture was taken). This means much faster page loads and much less work for Apache/PHP (or whatever web server setup you use).

For typical Magento installations, a small portion of your traffic requires you to change something (like adding cousin Larry to the picture), which can require getting the whole gang back together (PHP/Magento/MySQL). In the case of Magento, this happens for a small number of your users when a user logs in, adds something to their cart, starts checking out, or you’re in the admin panel, which renders new HTML for  every single page load. With Lightspeed, a fully re-rendered page is required only occasionally for your customers. If your admin is “too slow”, you probably have problems that a hardware upgrade could address.

NOTE: If you’re not yet in production, and ALL pageloads are slow, Lightspeed is most likely not properly configured and not running at all. If you’re not sure, add a URL variable to the end of the page address “debug_front=1″ — IE http://mysite.com/?debug_front=1. Lightspeed is running if you get a “success” message. If not, you’re not configured correctly.

If occasional page loads “requiring the whole gang” are still too slow, better server hardware and/or configuration may be required. A possible solution may be available by simply talking with your hosting provider or IT department for more information about different hardware and/or optimizing PHP, MySQL, or Apache alternatives.

While a hosting provider may be able to help, Lightspeed provides another way to reduce the number of “family reunions”. However, this solution is more technical for your developer. It’s called hole-punching.

What can I do?

To go beyond 90% of Lightspeed traffic on a Lightspeed installation, mix and match the following options with careful consideration of the labor, skill and monthly costs required for each:

1. Consider changing your server configuration or hardware - This can be expensive, but without technical knowledge, it’s an easy way to make everything proportionally better. If you meet these requirements, you’re probably okay hardware wise.
2. Hole-punch your site - The time and skill required isn’t “quick” or “easy” in comparison to a 30 minute, basic Lightspeed install (several hours to several days, depending on your developer), but in the long run it’s a cheaper solution than higher monthly hosting costs.

What can I do with server configuration? – Hardware seems expensive? We know! You can do so many things with server configuration! Here are two of the biggest points of slowdown we’ve seen (may not apply to everyone):

1. PHP Accelerator- Look into a PHP accelerator or different engine if you’re using modPHP. If you have a provider or IT department that can configure this, it will help.
2. Ditch Apache - You may have always trusted Apache, but that might mean that you’re getting up there in years:) In terms of web servers, Apache is old and outdated. Informed critics will agree that it has weak points and Magento experts will tell you that Apache can crumble in certain scenarios. There are a ton out there and they aren’t hard to use (Nginx, Litespeed (not our module), SimpleHelix, etc…)

What about hole-punching? – Hole punching is loading only small dynamic elements into a fully cached page (adding cousin Larry to the photo without having to take a new picture). Magento reloads the entire page when dynamic content is required for a shopping cart or logged in users, for example. Hole-punching can be very powerful, combining the benefits of high-speed caching and dynamic content, but this process is not for beginners. Here’s how that can be done.

Down To Business

Warning: I said hole-punching isn’t for beginners. It really can be complex. Even the most skilled Magento developers may require a couple of hours to successfully punch holes in a site they’re deeply familiar with. If you’re still reading, but not in that category, you’re either willing to brave the amount of time for the increased benefit (faster pages to users with product in their cart), or you will be talking to your developer or IT department about this process.

If you’re still not deterred, let’s continue. We’ll walk through punching a single hole as an example. It’s a very common punch around the links at the top of a page to show if a user is logged in and if they have any items in their cart. After that you should be able to punch holes wherever you wish, with some practice.

When hole-punching, I usually split things into the punch and the fill. It provides opportunity to debug along the way. I’ve separated example files in this way so there’s no confusion:

HolePunching_Example.zip

For most of these steps I’ve taken I added HTML/XML comments with the word “TinyBrick” into the code around lines that I’ve added to the default files in Magento.

If you have trouble finding the files on your own server, and desperately want to ask me questions, that’s probably a big red flag that you’re in over your head.

Punching Holes

1. header.phtml (app/design/frontend/{your namespace}/default/template/page/html/header.phtml): As you’re probably already found, templates like this is where you put HTML. Here you’ll decide what content you need punched out of the cached version of the page. You’ll just need to surround the HTML you need to retrieve dynamically with the NOCACHE tags (refer to my example header.phtml for syntax). It’s important that you also add a key unique only to this hole punch. This can appear on many pages…so make it unique from any other hole punch key name you think you’d use in any other hole punches you want to make. Lightspeed will use that key to determine what dynamic content goes where. In the example header.phtml, I’ve done this around the links at the top where you would want to punch a hole for cart and logged in status.
2. page.xml (app/design/frontend/{your namespace}/default/layout/page.xml): I haven’t changed anything here, but you’ll need to see where I’ve gotten some of these values to understand the rest. If you look at line 41, you notice that it is a child block within the header block (lines 40-48). We’ll need the value of name (or “top.links”) later.
3. Next we test! If it all worked correctly, then after you cache your catalog (or CMS) page, simply login or add something to your cart. The links at the top should disappear or be punched from the cached page. If you’ve gotten this far, you should know that you just punched a hole in your cached page successfully. Congratulations!

Filling Holes

Because of the way Magento is built, filling holes with content usually just involves calling specific blocks again to let Lightspeed fill the hole-punches using those blocks. However, sometimes Magento will nest blocks, forcing you to load entire parent blocks and all their children just to access one child block. This is the case with the particular hole-punch we’ve chosen, but like we saw in page.xml, the parent block for the header only loads a few sibling blocks, so this shouldn’t be too labor intensive to fill properly.

1. First we’ll need to install the example module that I’ve built to fill hole-punches (feel free to build your own or add an action to an existing controller). Take the folder Hole-Filling/Delorum and copy it to the app/code/local folder. Also, take the Delorum_…xml file in the folder Hole-filling and copy it to the app/etc/modules folder. That should essentially install this quick little module, which you need to do only once. You can re-use this module to fill as many other hole-punches as you like. After it’s installed, test this module by calling the indexAction of it’s controller — http://yourbaseurl.com/lightspeedcontent/hole/index. If it was installed correctly, you should get a blank page that only displays the contents of an array with a “Hello World!” value in it. If not you’ll probably get a 404 error.
2. catalog.xml (app/design/frontend/{your namespace}/default/layout/catalog.xml – This applies to cms.xml as well for the cms_page node as well on a default Lightspeed install): This is the layout for the catalog pages and product pages. To tell Lightspeed to fill holes on this/these page(s) add the holecontent node to the pageCache reference you’ve already added (with the install instructions PDF). I’ve done this in the example catalog.xml on lines 77-83 and 160-166 (21-27 in cms.xml). This will tell Lightspeed where to go to fill the hole in each page layout.
3. HoleController.php – in the Hole Filling example folder (app/code/local/Delorum/Lightspeedcontent/controllers/HoleController.php): Nothing to do here right now, but let me explain. In here, you’ll craft the individual pieces of content that Lightspeed will use to fill each hole-punch. There are several methods of getting content to fill hole-punches. Which method you use is up to you. The way I’ve done it is fairly typical for this particular block.
You’ll notice the IndexAction (another example is in the documentation) contains an array called $content. In this array you’ll use the key you chose in step 1 of Punching as your array key in this associative array. The value is whatever dynamic content you want to load into that particular hole-punch (currently “Hello World!”). If you know PHP or Magento, you can probably imagine where this is going. Just to complete the example though, let’s continue.
4. Test time again. Repeat the test you did in step 3 of Punching. You should now get a “Hello World!” message instead of missing links at the top. We’ve now successfully filled a hole-punch. How does it feel?

After-note: Now I’ve inserted two copies of the $content array (in HoleController.php) because I’ve found the most success starting with a test message like “Hello World!” Once that’s working, insert the actual content you’d like to fill the punched hole. For completeness, you can uncomment the second $content array and line 13 in addition to commenting the first array again. If all goes well, this should properly fill the hole punched around those links with the original content.

Phew! I hope this example helps with your hole punching expedition. Feel free to provide feedback in the comments. While hole-punching can be difficult, my hope is that this short tutorial puts it within reach for more developers.

Well, we’ve just released another extension, this one centered around Magento order edits. We’ve worked through this solution a couple of times for other clients, working out the kinks. Essentially there were 3 issues we tried to address.

1. Elimnate Magento’s duplicate order on edit
2. Make editing an order more user friendly for Customer Service Reps
3. Provide flexibility for developers to adjust the module as needed

The first is obvious. We had fulfillment systems that required Order Edits to maintain the same number, rather than creating a renumbered, duplicate order. Now it does. Saving edits fires an event, allowing any payment modules or fulfillment systems to collect the updated order information. Once complete, the page will refresh and display updated information for Customer Service Reps.

The second is more extensive, and involves how a Customer Service Rep interacts with the edited information. On the Order View page, we included the ability to edit each portion of the order in one location. Editable options on the Order View page are sectioned and arranged as follows:

1. Comments: A field is labeled ‘Reason for editing order’ is required, and is logged in the Comments History section when an edit is saved.
2. Billing Address: This section contains the order’s Billing Address information, including telephone number. Edit content by simply re-entering values or select from the dropdown lists.
3. Shipping Address: This section contains the order’s Billing Address information, including telephone number. Edit content by simply re-entering values or select from the dropdown lists.
4. Shipping & Handling Information: Current rates for an updated shipping address are displayed. If no new selection is made, there will be no modification to the Shipping Method or Order Price. If a change is required, simply select the radio button next to the Shipping Method indicating the desired change.
   A ‘Get new shipping methods and rates’ link will retrieve current shipping rates, based on the information in the Shipping Address fields. This function retrieves rates based on the values which exist in the 
Shipping Address text boxes, rather than the order’s saved Shipping Address. 
It is recommended to retrieve new Shipping Methods and Shipping Rates if the order’s Shipping Address has been updated.
5. Items: There are three operations available with Product updates: Edit, Delete, and Add. When Editing or Adding an item, you can change the price, quantity, or discount the item.
   * Editing: Edit a product’s price directly on the line item. Simply type the desired value for that product.
   * Deleting: Click the ‘Remove’ link at the right of the line item. When an item is marked for deletion, the details will be grayed out. To keep a product that has been marked for deletion, click ‘Undo Remove’.
   * Adding: At the right of the Items Grid is a button labeled ‘Add Item’. Click to Add new products. A new row will appear, requesting a SKU. After entering a SKU – and upon leaving the field – price, quantity, and name for the product will appear. You may then enter quantity, and if desired, a custom price and/or discount amount for the new item.
6. The Final Save: When all order information is correct, click the ‘Save Changes’ button at the top of the page. This will save all information to the order, and recalculated totals based on the new information.
7. Comments History: The module tracks order updates, appending changes and the required Reason Comment to the comment history. Comments record changes, date and time stamp, user making the change, and the original values which were updated.

The third objective was accomplished through architecture and a brief note to developers in the install documentation. We allow additional custom sections to be added relatively simply. Each section includes an updater file that handles its own saving, and documentation details the steps to create and add another section to the Order View Page.

Overall, not bad for those dedicated enough to find this module buried on our site

Since our first Magento client, we’ve  thought you ought to be able to add a product to the cart, and get another product automatically added to the cart for free without having to bundle the products. We like the conditions available in Magento Shopping Cart Price Rules, and naturally expected to be able to leverage those to trigger the addition of a product to the cart. Now we can, and by extension, the rest of the Magento Community can as well.

The module allows the creation of Shopping Cart Price Rules as they currently stand in Magento, but adds an additional action which automatically adds product(s) to the cart for free. While bundling products together seems to accomplish the immediate need, this module provides the ability to set a rule once for an entire category, and layering conditions (ex: 2 jeans, Men’s category, priced above $50 ea.). Obviously, there are benefits for this flexibility.

The module does have a single restriction, which we may address in the future: a condition which does not specify actual products (ex: shopping cart subtotal) MUST be layered with a condition which does. Any rule using this new extended promotional action must include at least 1 condition to specify product (sku, category, item price, etc.). We can live with that for now.

As an additional note, we are releasing True Edit Orders within the next few weeks… if luck holds.

This new version of Lightspeed more accurately clears cache tags. This means you’ll only be clearing the cache on exactly the items you update.

This newest version can be downloaded from the account section of store.delorumcommerce.com. Just click on the Download tab of the Lightspeed module. After you’ve downloaded the new version (2.8.2), update your installation with a single command from the terminal: ./pear upgrade /path/to/downloaded/Ligthspeed.tar.gz

Be sure to check back often for new module releases and updates.

A common question we have is, “How does LightSpeed and Speed Booster differ and how do they compare to Magento Caching and AITOC Magento Booster?” The biggest difference is block caching vs. page caching.

Magento uses block caching to reduce page load time. When a page is requested from the server, Magento knows which blocks make up each page, and requests those cached blocks rather than calling the database. AITOC uses a very similar method, but also compresses CSS and JavaScript.

Tiny Brick Speed Booster also uses block caching for Magento. Speed Booster automatically caches the most frequently used elements of your site, and configures them properly for caching. When you make changes to categories, products, CMS pages and CMS blocks individually, Speed Booster will recognize the individual changes resets the cache for you.

This allows Magento to serve up to 10x more requests per server, and reduces the server response time as much as 70%. The biggest advantage of Speed Booster isn’t its speed, but its ability to handle 50+ concurrent users without stressing server capabilities. This has allowed previous customers to reduce the number of servers by up to half.

LightSpeed includes all the advantages of Speed Booster, but caches entire pages. It sits in front of Magento, checking to see if a page has been cached. If not, it allows the request to go Magento, then caches the entire page as it returns. This dramatically reduces the load time relative to block caching.

Lightspeed also allows for full page caching, while allowing for dynamic content. After returning an entirely cached page, Lightspeed “punches holes”. These “holes” are filled by a much slimmer call to Magento for only the missing dynamic content, such as login status, cart status, recently view items and compare products. This results in a much quicker Magento response for the customers you most want to impress – logged in customers and customers who have already added product to their carts. Other caching solutions do not cache in these instances.

LightSpeed Magento Module

In summary, block caching provides Magento with quicker response times by saving block level content. Speed Booster takes caching to the next level by caching entire pages (load times in around 0.5 to 1 second). Lightspeed goes even further by returning entire pages, then replacing dynamic content as needed via “hole punching” (load times in around 0.1 to 0.3 seconds).

In April Google announced that they are officially considering page load times as part of their algorithm. Google decided that this is important because users spend less time on slow sites, and quick page load times make happier users.  From an SEO standpoint load times don’t carry the weight of relevant content or incoming links, but in competitive keywords, load times can give you an edge on the competition.  According to Google any page load slower than 1.5 seconds is slow.

Google Page Load Time Graph

Magento based sites have no problem getting under these benchmarks as long as the site doesn’t a have a notable amount of traffic.  Examine this benchmark from Magento. Response times are quick until increasing traffic causes the site to slow. That slowing grows exponentially.

Magento Page Load Times

Prior to launch, RedMarbleSteaks.com saw very slow response times. With no Magento Caching, they have response times of 6.07s. With Magento Caching, things are still relatively slow with only 25 users at 1.21s.

Compare with Lightspeed Caching, which produces a 0.12s response time with 40 users and 0.23s with 80 users. The transaction rate goes from 20.2/s with cached Magento to 342.15/s with Lightspeed Caching.

Magento Speed Benchmark

Google ranks website largely on elements related to user experience. Lightspeed makes the user experience better, increasing the likelihood that users will return and shop again, by reducing page load times and speeding the shopping and check out processes.

I’m the almost business guy, so don’t expect a lot of technical information as you read this. However, there are some interesting Magento / Environment things happening in our office that are worth mentioning. I’ll do it, since the real technical people are busy changing the world.

Our big push right now is extending the limits of Rackspace’s cloud environment. We’re finishing an enterprise ecommerce deployment that’s fully scalable, billed only for the hardware / bandwidth usage (which means automatically down to 1 web server at night, up to 6+ during peak traffic) in a totally secure, redundant cloud environment. Amazon has tools that make this possible, but the business guys for this large client said “No” (some sort of corporate jockeying).

None of that is supposed to be technically possible with Rackspace… according to Rackspace. It’s taken a few custom tools to trigger auto-scaling up or down, and somewhat circumventing Rackspace to tweak their own system (nothing illegal implied). The result allows a secure network, with communications fully encrypted, all within their cloud environment.

The potential for clients is tremendous cost savings, instant scalability and fully automated redundancy, not to mention a pretty robust disaster recovery model.

Rackspace doesn’t know that they offer all this yet, but if you know the right developers, it’s available now. It’s late, but I’ll come back to this one.

Several years later…

After creating high-availability, scalable private cloud infrastructures for Magento, we realized developers need a simpler solution to manage infrastructures themselves. We just built and launched Pagoda Box to bring fast, scalable cloud PHP hosting to everyone. See for yourself.