Magento SVN Usage – Best Practices

In this article we talk about best practices around using Subversion (SVN) with Magento to help you maximize its many benefits. Anyone who works with Magento will be interested in this easy to understand capabilities and benefits overview of Magento SVN. Whether you’re a store owner or a developer, SVN can make your life easier.

Quick Summary

  1. High-level explanation of SVN
  2. Who should use SVN?
  3. Why it should be used?
  4. Specific things to watch out for with Magento & SVN
  5. Bonus: Tools for the Trade

SVN-Environment Relationships

1. High-level explanation SVN

SVN (aka Subversion) improves the development process. Its an evolution of CVS (aka Concurrent Versions System) which allows developers to maintain local, staging, and production environments. It’s best practice for most software development (and Magento) projects to utilize some type of version control system. Git is worth noting as an alternative to SVN. The main difference being that Git stores everything locally whereas SVN stores things on a repository hosted on a centralized server where all updates are pushed and pulled. Typically people either prefer SVN or Git, both have good reasons and arguments. But for the purposes of this article, though, we are laser focused on Magento SVN usage and not so much the argument between which is better to use.

Simply put, SVN is a tool that keeps a revision history of code over a period of time. You keep project code located within the repository and pull a copy of the entire code with one simple command. As people work on the project, updates to the code are committed to the repository, which allows anyone who is “linked” to the repository to sync their code with the latest changes via one click of a button. A simultaneous, multi-user environment is organized for team-based development and proper administration.

There are an incredible number of benefits to SVN… too many to mention here.

2. Who should use SVN?

Everyone who works with Magento should use SVN. As a rule of thumb, SVN should be used in any significant software development project (unless you use Git as an alternative).

3. Why SVN should be used?

SVN allows multiple developers to build simultaneously in an organized fashion with a detailed history of the progress. This ensures that the live storefront (production environment) is always intricately cared for and remains “open for business”. There’s nothing worse than an outage in the eCommerce world and using SVN with Magento helps you to hedge against such events as it relates to your code. Every developer has experienced early on in their career the inevitable mistake of removing a file via FTP, only left to realize that file is lost in space and no longer retrievable. Thanks to SVN, you will be able to recover and restore this file in no time. The developer’s life becomes easier; and your eCommerce business is safer. When used properly, SVN ensures reliability, integrity, speed, and fall-back recovery.

4. Specific things to watch out for with Magento SVN

In our experience, there are a few specifics to watch out for when using SVN with Magento. Without getting too technical, here are a few things we’ve learned along the way:

  • Watch out for the caching. Utilizing “SVN:ignore” is the key to allowing the local environment to cache correctly. I would recommend setting SVN to “ignore” for the following (at least) when maintaining separate environments:
    • /app/etc/local.xml (or use SVN lock instead for this)
    • /media/catalog/product/cache
    • /media/tmp/*
    • /var/cache/*
    • /var/report/*
    • /var/log/exception.log
    • /var/log/system.log
    • /var/locks/*
    • /var/session/*
    • /var/tmp/*
  • Create and execute test script. We’ve learned the hard way to stick to a quality test script as we merge different branches into the main SVN repository (used for production). Testing major changes in a staging environment prior to going “live” to production with the new changes can save a lot of heartache later on. Don’t underestimate testing your changes, especially with Magento’s complex architecture.
  • Create branches for project phases. Sometimes it helps to create a “branch” for each phase and a staging environment for each branch (assuming the project is large enough to call for it). This makes it easier to rollback and merge updates, if needed.
  • Keep the entire Magento directory maintained in SVN. Call us crazy, but we prefer to keep the entire Magento directory maintained via a SVN repository. We do this so that we can upgrade, modify, and perform other changes locally prior to streamlining the changes to the staging and production environments.

5. Bonus: Tools of the Trade

We fancy apps that make our lives easier. Who doesn’t? We invest a lot of time researching and trying out new apps to see how well they fit our business. So far we have found a few SVN tools that are worth mentioning. Note: some of these are Apple-specific.

  • VersionsApp: A high-quality desktop application that allows one to manage repositories locally for streamlined management of code.
  • BeanstalkApp: A sweet as online SVN storage service to host repositories full of code, revisions, and a great interface for management.
  • Coda App: A quality code editor that integrates with SVN
  • TextMate: Another quality code editor with SVN integration
  • MAMP: A personal Mac server with Apache, Mysql and PHP
  • VirtualHostX: A virtual hosting utility that works well with MAMP
  • VirtualBox: A sweet virtualization product to run multiple operating systems
  • A browser-compatibility testing tool

Those of you who are already familiar with SVN know that there is obviously much more to rave about. This post is intended to be a simplified “business use-case” for Magento SVN usage and explain why it is a Magento best practice. Please chime in in the comments below with other suggestions for everyone to benefit from!

How to jeopardize your business with ecommerce (and what to do when you’re in trouble)

It started innocently enough. The agency wanted a module for their Magento store. We built the extension and installed it for them. Problem solved.

Fast forward a few months and we’re down a team member. There’s a lot of demand for Magento services, but we continued to struggle to maintain profitability on projects. It was time to question our business assumptions (Seth Godin recommends that bootstrappers question everything about their business every 90 days).

At this point the agency owner dropped me an email with a new request: “Do you guys do web stuff other than Magento? Because I have another client who needs someone to design and code a CMS site.” We accepted the gig in order to begin testing different business options. After a couple of WordPress and Drupal builds we learned that CMS projects, while usually smaller in budget than ecommerce, were actually more profitable.

Succeed with Magento

Now before I move on let me clarify something. Some firms do in fact make great money on ecommerce and Magento. I see two clear ways to do this:

  1. build a product. There’s a Magento services company that generates $10-15k/month off of the residual sale of one module. This module has single-handedly kept them afloat in months when project budgets are upside-down. If you plan to weather the ups and downs of big deals, then you would be smart to hedge your bet with monthly stable cash-flow. Plus modules will attract more business and establish your credibility.
  2. skim off the top. Magento is enterprise ecommerce. It should come with a warning that states: “Not suitable for small retailers, startup ideas, or little children.” So get your prices up and go after established retailers with big budget expectations. You might even want to become an Enterprise Partner with Varien to get into the big deals.

Unfortunately your friend who saved $5k of his own money to have you build a store for his knock off version of threadless is out of luck. He’s caught in the no-man’s land between Shopify and Magento. Feature requirements are too much for the simple systems and too expensive for you to help him out with Magento while keeping your doors open.

If you heed these warnings then you can avoid a lot of the stress and pain that we had to endure.

Web Agency Playbook

Many web design firms target customers based on location. Some start by building sites in their spare time for friends and acquaintances. One referral leads to another and all of a sudden they have 5 guys churning out work for the local bank, YMCA, and Jimmy’s Pizza. Anxious to get away from customers who don’t understand the web enough to spell HTML, these agencies look for specialties to pull in bigger fish.

Along the way someone will inevitably ask the web firm, “Hey, do you guys do ecommerce?” Enticed by large deal potential the agency owner replies, “Absolutely.” Then they go back to their office and google open source ecommerce to compare feature lists. Meanwhile their developer curses under his breath for the boss’s assumption that ecommerce can’t be that much harder than coding WordPress. This story rarely ends well.

An agency in Oregon has been building websites for 10 years. They created their own CMS system only to abandon it in favor of open source options like WordPress. Last year a client asked them to build a Magento store. My agency friend confessed that he has lost money on pretty much every Magento project they’ve done since. $5-15k CMS deals keep the troops fed. “Why do you keep doing ecommerce then?” I asked. “Because we keep getting asked,” was his answer. At some point you have to realize that it’s silly to do the same things over and over but expect different results. I’m curious what would happen if this guy focused on the profitable side of his business. Sometimes what you say no to defines you more than what you say yes to.

90 days at a time

Elias is implementing 90 day business model sprints. That means we’ll set our sights on a focused target for 3 months without questioning strategy. At the end of 90 days we circle up, measure progress, question everything, and set a new objective for the following 90 days. It’s our way of balancing focus with new potential opportunities.

Objectives for our current sprint include:

  • 9 CMS customers. Agencies like the one I mentioned above are starting to send us design and development projects. Most deals are for wordpress and drupal builds in the $10-20k range. They tend to be established companies with dated websites who want us to take their online strategy to the next level. Please drop us a note if you know someone who might fit this mold.
  • 4 Magento consulting and development projects. Existing customers depend on us to make their business work with Magento. We take the trust these guys place in us very seriously. That’s why the only Magento time we’re selling right now is already dedicated to their success.
  • build new elias site. Our current layout is not helpful for new or old customers. Copy that emphasizes Magento development is unnecessarily confusing for home healthcare providers, churches, accounting firms, and other organizations who want a new website. On the other hand, Magento users continue to submit requests for help with modules. We gave the module store to Lee when he left in exchange for his equity share. Lee then sold the store to a great group of Magento pros, Classy Llama. That’s why the module link on this page redirects to their url. Meanwhile, traffic continues to flow to our Magento blog posts. We’re considering the sale of ad space on those pages to reroute leads. Email me if you’re interested: josh [at]
  • thinkgroup with web companies. The email and comment responses from our post about breaking up with Magento have been tremendous. I’m trying to follow up with everyone who provided feedback (I apologize if I haven’t had a chance to respond yet). A number of you felt that the transparency was refreshing and wish that you could connect with other colleagues to exchange ideas. So I would like to form a group of 5-10 owners who want to talk shop. Again, you can drop me an email if you want to join.

Breaking up with Magento

It’s not you, it’s me. This relationship has had its share of ups and downs. Yes, we’ve become known as a Magento shop. Yes, change is scary. But we want to date other business models and platforms. I hope that we can still be friends.

man talking to upset woman

A Brief History

Elias started as a couple of guys doing after-hours freelance web work. One customer wanted an ecommerce site and liked the features in Magento’s beta version. It took forever to code because of limited documentation, but we felt that the market was ripe for a new open-source ecommerce system. Our total bill to the client: $5k. When you factor in time we probably definitely lost money; but we gained new skills in something poised for growth.

Over the next two years we took on about 30 Magento projects and fostered relationships with stellar developers. But it wasn’t smooth. The first quarter of 2010 ended $10k in the hole because of two projects that went well over their deadlines. Tensions were high. Clients became increasingly frustrated and we lost money each day the projects dragged on. Plus we couldn’t accept new clients without more bandwidth.

Q2 made up the deficit. I attribute this to three things. First, we hustled. Long hours were spent churning out work for several new customers. Second, our business transitioned from a fixed-estimate pricing schema to a more agile hourly rate. This hedged us against a recurrence of those Q1 project misquotes. And third, we added products. We had amassed 16 Magento extensions at this point and put 8 of them on a basic Magento store install to see what would happen. By June the store was generating almost $2k/month – 90% of that tied to one module. The store had potential, but it needed a lot of work to improve on the alpha-esque quality.

Tipping Point

Magento-based work took its toll on our team. We might have pulled through Q2 in the black, but our personal income was laughably poor for the software world. Compounded on top of this was growing dissatisfaction from our Magento guru, Lee. He was a capable developer but didn’t like being an isolated coder on a virtual team.

Lee and I grew up together in the same small town. He was a friend long before either one of us knew what PHP is. So it was important to our ownership team to help him figure out where he fit without forcing him to continue doing something he disliked. Lee ultimately felt that stepping away from coding and the startup environment was the right call for his family. Eric, Luke and I committed to support and cheer him on even though losing him meant shaking up our business strategy.

Where do we go from here?

Over the past 60 days I’ve looked at several ecommerce and CMS communities, talked to development leaders in the Magento community about forking, documented the elias 10 step website process, and littered my office floor with papers covered in research notes. I’m always open to listening to new opportunities (unless you’re an offshore company spamming me with grammatically incorrect offers for cheap labor). Drop me a note if you have suggestions for a new product or approach: josh {at}

Practically, the module menu redirects to a store that Lee is managing until arrangements are finalized with a buyer. Magento-related leads are being diverted to trusted colleagues for now while our team is working hard to finish new projects in design/development. A refreshed elias site layout is in the works for this month and I’ll discuss strategy in an upcoming post.

Dreaming In Code

I’ve had a string (play on word there with a reread) of dreams where I was actually (and unrestfully) thinking of a creative way to twitter about my dream. Something like…


…is what I’ve got so far under the zzz’s.

Just unfortunate I can’t control my dreams any better than this.

Magento: What would you like to improve?

What’s your biggest Magento pet peeve? We asked this question over a year ago on our blog. Today I reread the post’s comments. It seems like the same issues could still be regurgitated.

A driving goal for Elias in 2010 is to build tools that allow Magento storefronts to sell more and Magento developers to do more. So I’m resubmitting our original question with a new spin:

If you could change/improve one thing about Magento, what would it be and why?

Configurable Bundle Module Upgraded for Magento v1.4.0.1

We just upgraded the configurable bundle products module to v1.4.0.1. So if you were thinking about purchasing it for your store but were concerned that it won’t work with your more recent version of Magento – fear not.

Have a suggestion for future features & improvements to the configurable bundle product? Let us know so we can consider it for the next release.

Magento: Quick Change in Column Count for Products Displaying In Category Listing (Grid View)

Hi All,

Figured I’d share a quick Magento snippet (There are several I’d like to share each day. For some reason this particular one seemed quick enough to post).

Want to change the number of products that display in the Magento Category listing?

You’ll need to modify these two files:

  • app/design/frontend/default/YourThemeName/layout/catalog.xml (default theme line 198)
  • app/design/frontend/default/YourThemeName/layout/catalogsearch.xml (default theme line 61)

See the screenshot for the variable columnCount()? In order to change that, go to the following file and add in this snippet:

  • app/design/frontend/default/YourThemeName/layout/catalog.xml (default theme line 198)
<action method="setColumnCount"><columns>3</columns></action> <!-- set your own number -->


And also this snippet:

  • app/design/frontend/default/YourThemeName/layout/catalogsearch.xml (default theme line 61)
<action method="setColumnCount"><columns>3</columns></action> <!-- set your own number and insert <em>inside</em> the "search_result_list" block tags-->

Magento Service Packages Design

Estimating service pricing on a client-by-client basis can be difficult and time-consuming. It’s risky for the service provider because they invest time before receiving a commitment from the client. And clients can get annoyed when they have no expectation for cost early in the relationship.

Houston, we have a problem

Elias faces this tension on a daily basis. Let’s say we receive an estimate request with project description from a new potential client. Ok, now what? We try to get more information. The potential client is trying to understand price. And agency partners want a faster way to incorporate Elias development costs into their bids for client Magento ecommerce opportunities. So I created packaged services to frame scope and help clients see the effects of feature configuration/development on price.

Solution (v1)

  • Package services for typical client requests to quickly set expectations for scope and budget.
  • Reduce package variation to minimal number of factors.
  • Establish a conversational starting point when discussing a project with a new client.
  • Make the purchase decision easier for clients.
  • Distill scope differences between packages into an easy to consume format.

Result (v1)

Packages v1
Packages v1

While this initial version of our Magento service packages did set expectations for scope and budget upfront, it failed on multiple levels of design:

  • The pricing was not simple.
  • Awful borders held the table captive.
  • Don’t even get me started on my poor original names

Solution (v2)

Tyler Tate recently featured a fantastic article in Smashing Magazine about minimizing complexity in user interfaces. He illustrated one of his points with a pricing chart from Typekit. Their example gave me the inspiration I needed to create version 2 of Elias’ packages:

Result (v2)

Packages v2

SSL in a Nutshell

Clients frequently ask us for Secure Socket Layer (SSL) certificate recommendations. There seems to be a lot of confusion surrounding SSL – everything from why they’re needed, how they work, what they do and how to install them. Let me demystify some misconceptions and answer common questions in today’s post so that you walk away with a better understanding of SSL in general.

Why SSL is Necessary for eCommerce Stores

More and more online shoppers are becoming keenly aware of the affects of identity theft, and thus most know to look for a secure connection when shopping online. Without a secure connection, you run the risk of losing customers. Shoppers want to know that the website they’re on is safe and can be trusted before they give out personal information or complete a transaction. SSL provides that security both visually in the browser and functionally behind the scenes.

How SSL Works

I’m a visual person, so I found this graphical representation of SSL to be very helpful in understanding what’s going on behind the scenes without getting too far in the weeds with technical jargon. (Thanks to the folks at for this.)

Who’s who in the SSL world?

There are many providers out there, but three main players lead the SSL world: Verisign, Comodo, and GeoTrust. I’m confident you’ve at least seen or heard of at least one of these players. All three are perfectly fine and trustworthy providers. We have have not had a problem using any of these three providers with our customers at Elas. Choosing an SSL provider should be based on client-specific needs, so I recommend you check out this article at eHow for some tips on selecting a provider.

What is extended validation (EV)?

Think of EV as an add-on for SSL. EV is what triggers the address bar to turn green in some browsers while on a secure site. Not all browsers do the same thing, but each browser has some special visual element that indicate you are on a site with an SSL that has extended validation. Studies have shown EV to be very effective in building trust with customers. However, EV doesn’t come cheap. You can expect to pay at least $450/year for a quality certificates with EV.

OK, so why are some way cheaper than others?

The cost of certificates varies quite a bit depending on a number of factors such as how the certificate is validated, warranty coverage, wildcard certs, brand, etc. The leading driver of cost difference is how validation occurs. There are two main ways to validate a certificate.

  1. By domain. Only verify the domain ownership of the purchaser, and thus have much faster turnaround times since none of the additional information needs to be verified. Sometimes available for implementation within minutes.
  2. By organization & extended validation. Requires the certificate authority (the company issuing the certificate, such as GeoTrust or VeriSign) to verify the purchaser’s business and their authority to purchase a certificate on behalf of that company. These are considered higher assurance certificates and are generally perceived as more trustworthy.

    What benefit is there to purchasing a higher assurance certificate?

    Low assurance certificates that perform domain-only verification encrypt just the connection. Higher assurance certificates perform the same encryption and provide peace of mind to customers by assuring them that the entire site belongs to a legitimate business.

    There you have it – SSL in a nutshell! This is by no means an exhaustive dissertation, but it should equip you with a working knowledge of the SSL technology that is a necessity with today’s ecommerce sites. We’d enjoy any comments or feedback from your own SSL experience and expertise. Cheers!