Lifeguard Press specializes in licensing, private labeling, manufacturing and distributing products within the fine stationery, gift, and tech accessory industries. Their collections include top-designer brands and they offer top-selling items such as agendas, calendars, cases for iPhone®, smart covers for iPad®, tech cases, market bags, stationery and more.
Lifeguard Press, Inc. launched the first iteration of their e-commerce site in 2008, powered by osCommerce. After successfully growing revenue year-over-year, it became obvious that osCommerce would be unable to meet their future goals and expectations. They enlisted the help of Louisville Web Group to manage the migration and conversion to Drupal.
Louisville Web Group has been building websites and helping clients succeed online since 1998. They focus primarily on e-commerce applications, and develop in Drupal and Drupal Commerce.
Coupled with the Commerce module, Drupal provides an e-commerce platform with unparalleled flexibility and content management features that are simply not available in any other e-commerce system. This was important not only for ease of use for administrators and future implementation of various business processes and initiatives, but also to maintain and improve SEO and other marketing efforts.
The key goal of the project was to establish Lifeguard Press on an e-commerce platform that was stable, easy to maintain, and capable of customization. This would provide them with a solid foundation for future growth and initiatives. They also wanted the site to run faster and maintain best practice for performance.
Over the years, Lifeguard Press had invested in various customizations for their site. These had to be duplicated and integrated into the Drupal way of doing things. This was also an appropriate time to implement improvements.
Lifeguard Press sells several lines of products that can be personalized, such as invitations and serving trays. From a customer perspective, this worked fine. You could change the text, the font and font size, the color, and the alignment of an area of the product.
On the administration side of things, however, there were clear improvements that could be made to help with staff workflow.
Limitation 1: They previously had to rely on developers to add new font and color options for the tool.
Solution: We implemented two custom entity types. The font entity has a file field that accepts a .ttf file, and the color entity has a text field that accepts the 6 digit hexadecimal color value. It is now very easy for an admin to create new fonts and colors, and to edit existing ones.
Limitation 2: The previous site had personalization templates where you could select how many text box areas there were, and where they were located on the product, etc. However, these were tied to their individual product. Many templates have the same number of fields which would hold the same type of data (for example, initials for a monogram), and the cloning process could be very cumbersome. There was a lot of duplicated effort.
Solution: We created the Personalization Template entity, along with a template type bundle, so they could create Personalization Template Types. They could then create a Template Type that had the number of fields they needed, and they could create as many unique Templates based on that Template Type.
For example, they have a series of products that have monograms. They have the same number of fields that will be used for the same purpose, but have different values and positions. They now just need one Template Type, and they can create an unlimited number of Templates of that monogram type without having to define the fields and labels from scratch again. This helps centralize management and decouples it from their products.
For the personalization tool, we also created a custom “rich text” field type. This is simply a field that contains the text value of the field, along with associated metadata, like font, color, positioning, and alignment. This way, everything related to that field that we need is contained within the field itself.
For what customers see on the tool itself, we utilized ImageMagick and create images based on the fonts and other options the customers select. That image then becomes the background image of the relevant text box. This was the quickest, simplest, and most budget-friendly way to convert the personalization tool and keep it cross-browser compatible. If we had gone pure CSS, then admins would have to manage font files beyond a single .ttf file. This would have increased the overall complexity, and be more sensitive to the quirks of different browsers.
This is something that may eventually be upgraded in the future to take advantage of other technology, if the ROI is there.
The previous site exported orders in a way that could be imported into QuickBooks with third-party software from Synqware. We created a custom module with a URL accessible by the importer, which looped through recent orders and printed out the relevant info in the proper format. Entity metadata wrappers make this type of operation relatively simple.
The previous site had a section where visitors could enter their zip code, and get a list of nearby retail stores that sell their products. There are currently over 2000 stores, so this was not something that could be done manually in any sort of timely fashion.
With Feeds and the Location Feeds mapper, we simply took a CSV export from the old database and imported it into the new site. The Location module, coupled with Views, provides a proximity search right out of the box.
Lifeguard Press took this opportunity to refresh the design, one that showed off the larger product photography that would be on the new version of the site. They provided mock-ups of the home page, product listings, product page, user account page, and checkout pages.
The checkout pages in particular broke the mold of a typical Commerce checkout process, but implementing it turned out to be straightforward with a module that added some extra DIVs and content to the checkout pane forms, and a few extra Views blocks displayed appropriately to the right.
On the old site, each product had its own unique page. However, many of these products group naturally together as they are essentially the same product with just a different pattern. Lifeguard Press wanted this natural grouping represented on product pages to make it easier for customers to recognize what they were getting, and what other options there were.
However, on the product listings and search results, they wanted each individual product to be shown so visitors could get a sense of what could be purchased without having to dig too deep. If a visitor clicks on the product, it takes them to the product display.
But how to get the product display to show the product the user clicked on? By default, Commerce does not have unique URLs for each product referenced on a product display.
This was accomplished with a small change to how Commerce determines the default product shown on a display. The listing view adds a GET variable to the end of each link to its product display that contains the unique Commerce product ID, and then the Add to Cart form checks if there is a “display” GET variable in the URL.
Custom Slideout Menus
Lifeguard Press wanted a slideout menu system with functionality that was not provided out of the box by any modules that we knew of. This required some custom blocks. However, we still wanted them to be able to add and change things easily with the already robust Menu management system.
So we ended up pulling in specific menus defined through Drupal with the API, and parsing and rendering them ourselves, to get the granular layout (multi-column) that was desired.
Rush Orders and Gift Orders
We added two additional options to the checkout process for the customer to check if needed: Rush Order and Gift Order. If the customer selects Rush Order, it adds a line item with a price to the order. If Gift Order is selected, nothing is added to the order, but the order is marked so fulfillment can know not to send any pricing information when they ship it.
Using custom fields on the Order entity, each of these options are reflected on the backend for admins to view them at a quick glance.
Category Banner Images
Category banners are displayed above the title on most category pages. This was simple to do with an extra field added to the relevant category terms. This worked for most cases, but towards the end of the project, it was decided that it would be beneficial to have different banners if the page was also filtered by brand.
For example, multiple brands have the same type of product, such as Agendas. Ideally, each brand page of agendas should have its own unique banner at the top for its category page.
Each term now has a basic image field, just like it did before, which it uses if it is not being filtered by brand. But each term now also has an image field for each brand that is shown instead when it is appropriate. This provides a lot of flexibility that is easy for site admins to manage.
Lifeguard Press had 4 years of data to transfer over. This included users, orders, addresses, and products. To accomplish this, we used the fantastic and robust Migrate module, along with Commerce Migrate.
Migrate makes it easy to track what has been imported, roll back your imports while you are testing and developing, and control your processes with Drush. We can’t imagine doing any non-trivial migration without it.
This was a straight one-to-one migration of the osCommerce users table. While we could not transfer passwords as osCommerce salts passwords, this pulled in all the email addresses and put them into accounts, so we would have something to tie imported orders and billing information to when the time came.
To get around the password limitation, users will just need to go through the normal Drupal “Forgot Password” process.
osCommerce orders have email addresses attached to them, and so we used that to tie orders to our imported users, since unique user IDs would not be transferred over. Line items were then given a straight one-to-one import. The only issue was shipping line items, which had to have its own migration class, because in osCommerce they are mixed and stored with order totals and subtotals.
We did two different migrations for addresses, one for Customer Billing Profiles, and one for Customer Shipping Profiles. osCommerce has an Address Book module that was being used, so we did a one-to-one import of those and made them Customer Billing Profiles.
Shipping address information, however, was pulled from each order, and then attached to the user whose email address matched that order.
Since Lifeguard Press would be updating their product photography during the development process, the product import was simpler than it could have been, since we did not have to deal with migrating files. We simply needed to pull over the titles, prices, SKUs, and other various metadata into appropriate fields on the Drupal side.
Wrapping it Up
Lifeguard Press is an established site with lots of traffic, getting orders every day. This type of scenario can sometimes make migration complicated. But thanks to the default functionality of the Migrate module, after establishing our migration classes and testing them thoroughly, we were able to establish a connection to the live database and run the initial imports, while keeping track of new orders and users that were being created each day on the old site.
Right before launching the new site, we ran a final import on all unimported items, and the new site had up-to-date data.
We have posted our osCommerce Migrate modules to this sandbox (which received a good starting point from the Commerce Migrate Ubercart modules), although the unique nature and requirements of most migrations will probably require additional customization and expertise. However, it might help give others a head start.
Lifeguard Press now has an e-commerce platform they can be confident with going into the future, and something they know can be maintained and customized to meet their unique needs. They have ambitious goals, and Drupal will be a good tool for them to use to help them accomplish those goals.
We have posted our migrate modules at this sandbox for others to use as they see fit.