Should I choose Drupal Commerce as my e-commerce platform?

Today are many options for running a online store, Drupal Commerce is just one more. Perhaps not just one more, but actually my favorite one; I do only serve Drupal Commerce clients as developer, but I’m also working on my own store over Drupal Commerce.

Before going further, I need to publically thanks to my friend and colleague Alberto Arancibia for the proof reading of this post.

Having the prefaces done, let me be clear about it: Drupal Commerce is not for everybody

Let’s start with the “should I”:

This post mainly is oriented to agile entrepreneurs selling physical products* online. If you are on Gov or legacy big business, where bureaucracy is more relevant than speed of implantation, then this post is so not for you.

(*) Digital goods are a complete different animal, where Drupal Commerce could also be very useful, but the platform choosing criteria should be from a different perspective considering the long sales funnel.

Worth to mention, this post it also came to life from a real customer situation, where my client reached to me already having a Drupal Ubercart online and running, and even when I think they should move away from Ubercart, is not clear for me if they should move up or down.

As a Drupal-only developer, I’ll lose a client, which may not be into my best interest. So I’m trying to put down this compressive post, so my client (and you) can build you own decision, and own it as yours, with the pros and cons.

Here I’ll propose you a criteria, but be aware: no external consultant can understand the inputs for this criteria as well as you, also bear in mind the benefits and/or troubles of you e-commerce platform will impact directly on you as entrepreneur and store manager. So, do your due diligence, re-read this post as many times as you need, check all the links, perform SWOT analysis and do whatever you do, when you make you serious business decisions.

Lets check out the options…

Hosted code or software as a service (SaaS)?

If you just want to be selling fast, just post you products to ebay, Facebook or instagram. But if you are looking for an e-commerce platform, I think you don’t want to compromise so much control over sales cycle; you want to control the catalog, customer communications, payments and so one.

But just in one level up, If you selling fancy handcrafted products, I think you should build you base products for 3 to 9 months on etzy before investing in your own store.

bigcommerce-logoAlso if you are in developed country, big commerce, yahoo shops and shoppify are pretty nice “out of the box” options, the downside is they don’t accept third party payment processors, so in local markets you can’t accept the dominant processors. Here in Chile these are Khipu and WebPay.

Also a huge advantage of hosted platforms, is the scalability: you can run million dollars operations in bigcommerce, shoppify and yahoo shops. Please bear in mind that it will be expensive, as they charge you a variable fee, as opposed to much more fixed costs over a hosted e-commerce platform.

The argument for the hosted open source: freedom and independence!

Using a software as service platform is pretty much like marrying your business with the provider. And I mean old style: If you want a divorce, you ask the Pope; if he denies, you need to create a new church over the English Channel.

When you value response to change, you should be always asking: how hard is to move away from this decision if we want to do it in the future?

SaaS always offer less exit options than hosted open source. This is because, the exporting tools will be always up to you provider, they have to create and put them for you. But also note they have no incentives to help you move away, and in the other side, you monthly fee is pretty good incentive to lock you up, they may do it gently, but putting exit barriers will be always in they interest, like most recurrent fee services.

So checking thoroughly exporting options, is an absolutely must if you are seriously considering SaaS options.

On the other side, when you are in control of the server and the code, you can always dump the database, write a custom exporter and mine your data as deep as you want. So moving away become an issue of technical work investment, but there are no dead end roads on hosted open source platforms.

Also be aware that you SaaS provider could change policies, features or prices at any time. Having a emergency exit plan, –at least writing a draft– will give you a way more accurate risk assessment about it.

Also, acknowledging we live in a post-ED-Snowden-internet, you may want to ask you self on the ethics of sharing you customer data with US based providers. In some markets, where you serve political opinionated or savvy IT security customers, this issue could take a lot of weight.

You can think about like renting v/s owning you store.

WooCommerce: The simplicity of WordPress + e-commerce


WordPress is everywhere; this Drupal blog is actually running on a WordPress. Why do a Drupal developer choose WordPress to run his drupal-oriented blog? Well, WordPress is a pretty the king of blogging, so let explore the sweet side first:

WordPress is brutally fast, cheap and easy to deploy and operate.

You can launch you WordPress in almost any standard hosting, and with cpanel softaculous you can even install it without leaving you browser windows. So you can be up and running in a couple of hours on almost any cheap hosting.

Many plug-ins availables

Even when most “good” plugins are paid, and WooCommerce’s are a little bit pricier than the others. Still beating the time and monetary cost of any custom developing.
There two main downsides: support is not way not first class, in WordPress forums is not hard to find customers complains about WooThemes (the developers of WooCommerce).
Also bear in mind out-off-the-box plugins as pre-made solutions, you need to adapt to them, not other wise. You can write custom code over them, but if you find in this path, I strongly recommend you to check the upgrade alternatives to WooCommerce in following points. Seriously, custom code on a WooCommerce: generally not a good idea.

Easy, cheap, fast and mobile friendly pre-made themes

You should go for WooThemes as they ensure compatibility with WooCommerce, and you will need to adapt to what is pre-made, but in general they offer a lot of customization, as long aren’t really strict with the design, you can have nice looking theme customised by you self expending $100 to $200 USD and 10 to 20 hours in the theme, extensions and plugins.
If you are starting a online store, specially if you value proposition is primary located in the products by them self, this an good option to test them against the market.

Huge community around: you can get simple jobs really cheap.

WordPress is the prep queen of CMSs, by far the most popular. This means there are a lot of developers available, you can find cheap providers overseas, and you probably can get somebody local too. In most cases probably be less expensive than a developer for other platforms.
With high popularity also comes a wide range of providers’ quality. Let me be more clear: WordPress community is jungle, you need to be hands on over quality, and you should set up quality procedures and standards to you developers, as most of them won’t do it for you, if you don’t take of this, each one will be doing things in their own way.

As you can see, we are moving to the downsides…

Limited pricing, taxes and shipping:

If you want to have complex pricing rules, or need to have complex tax control i.e. if you are selling alcohols to different US states or you’re selling industrial goods internationally where need to leverage in any free trade agreement you can.

In the case of my client, they currently offer 2 prices for each product, a get it now price, and one up to 20 days delayed-delivery price. If my customer wanted to just keep this pricing structure in the future, I think she could be ok with one task custom module for this, or a custom implantation of product attributes as they current have on Ubercart.

But if she wanted to further explore customer surplus and inventory optimization relationship. As long as the can stake up orders of same SKUs in batches, they could save at raw materials as orders are stack then they are making bigger size purchases.

A next level could go around adding a field to each SKU in order to set a “monthly batch delivery date”, so the delayed-deliver price difference with the get it now price can have a direct relationship with the delivery delay. For example a product which is set to batch produce on every 15th of the month, would have a pricing like this (daily or hourly self updated)

Date Get-it-now price Get it the next 15th price Days to wait
Jan, 1th $1.000 $770 14
Jan, 5th $1.000 $842 10
Jan, 10th $1.000 $932 5
Jan, 13th $1.000 not available, showing other products on sale 2
Jan, 16th $1.000 $500 30
Jan, 20th $1.000 $572 26
Jan, 25th $1.000 $662 21
Jan, 30th $1.000 $752 16

Implementing this can of feature in well build Drupal Commerce can take a 4 or 6 days and a rate of $500 to $1000 USD. That speed, for this level of sophistication; is just not possible in a WooCommerce.

The reason behind this phenomenon is because in WordPress, the coder will need to build this functionality almost from scratch. On the other side, Drupal Commerce allow developers to stand on the shoulders of giants, as you dev could implement this logic with flag and rules, then you will have not only a super robust code base for you pricing management, but also the store admin will be able to manage and edit this rules over the web admin interface, and that, is nice independence to have as entrepreneur.

Same logic can go for shipping methods, where you even could want to ingrate to a shipper API calculating costs on the fly based on you product size, weight, and customer location.

Note: Alberto –my colleague and reviewer of this article–, point me out in developed countries you can easily find drupal developers charging USD$200 / Per hour. I personally had pay USD$100 / Per hour to a highly specialized remote Drupal consultant in past, and bear in mind he didn’t write single line of code for me, he just talk me through my issues over skype (It totally worthed it). Also bear in mind if you use an agency as provider, they will have to charge you non-developer costs associated to agency operations (sales department, physical facilities, 24hrs phone support and so on). If you have hired a Drupal developer in super-expensive economy (like: Zurich, Hong Kong or N’Djamena) please let me know about you experience, it’ll make very interesting conversations on our local Drupal community.

Advanced web marketing, micro-customization and testing

Let’s said you want to show a banner with a special promo to customers who have seen at least 3 products from same category over last 36 hrs, perhaps a special offer of the category leader product.

Or you want to customize the whole site look and feel for visitors coming to a specific link; if you were a exclusive provider for a non competing web, i.e. you sell merchandising, and you want a custom mini-site for an game app. Then you would like then provide a custom entrance to you store, where you theme will drastically change, to mimic look and feel of the original site, to increase your conversions.

This kind of things are way of WooCommerce league, if you want them, you’ll need a more advanced e-commerce platform.

If you are want to evaluate further WooCommerce, check the 4 Risk of WooCommerce and do some research about the last item. Also check this tread and surf around WordPress support forums.

Other open source LAMP options: the middle ground

There are also other middle ground options, generally more powerful than WooCommerce, but not as much as Drupal Commerce. If you don’t have experience neither in Drupal or WordPress, one of this could be a good choice for you (if you already know Drupal, you should take advantage of it).

As it, please consider that costs a little more expensive than WordPress, and if you don’t live in big city, you probably have to hire a remote developer.

Prestashop highlights


If I previously convey that WordPress is the most popular at blogging, we should recognize Prestashop as most popular online store. It work pretty much out of the box, and is a basic but native e-commerce app.

Actually, let me tell you a secret, if you have few modest real-world stores, and you want to do inventory management at you site, at this moment (September 2015), I’ll advice you to go with Prestashop. Drupal Commerce fails miserably at that level (It can work nice with one and even two warehouses, but if you want more, you’ll need to jump to an enterprise integration that make no sense for frugal stores in less than 5 different locations).

Other good reason to my local market, is that prestashop is pretty popular in Spanish speaking world, so many store managers chose to work with remote, but Spanish speaking developers.

You can get many additional functionalities with its extensive plugins options, but be prepared to spend €500 – €1500 in plugins and theme just as a DiY project. Actually check out the Prestashop market place, it’s probably the best Prestashop store I have seen.

Last point for Prestashop is its lightness, It can run in almost any standard LAMP hosts like WordPress.

Magento highlights


Magento is the big brother of this category; plugins and custom dev are more expensive. But as Magento has a enterprise side, you will find highly specialized plugins that are only available for Magento.

Magento is a rock solid open source project, you can grow as big as you need in orders and products, and I’m talking about 10.000+. If I wasn’t went for Drupal, I’ll probably went for a Magento, but bear in mind I’m pretty savvy user, Magento is an advanced option.

I also heard that Magento could be lighting fast, but in website speed there are many factors involved, and an advanced platform, will let you control these factors with much more accuracy, but I haven’t done serious testing about, is just what I heard. You should do you research, and check how out of the box is the speed and also look for specialized hosting (you will need it).

Prestashop and Magento downsides: the CMS

Magento official web page is built on Drupal, and I dare you to find a nice page of Prestashop’s or Magento’s developers eating they own dog food. This is because native Commerce apps stink as CMS, so most entrepreneurs end having a CMS like WordPress + a Prestashop or Magento.

Having two different systems, means you need 2 different developer providers, infrastructure, procedures and so on if you want to run both optimal. Or you instead could compromise quality, simplifying operations through sharing generic developers, infrastructure and procedures.

You also should look the integrations you need to make between the two systems. If a customer wants to publish a product review on the CMS side of you site, should him register again because WordPress and Magento keep independent user databases? If you take the two systems paths, the integrations aspects is where you should expend most of you time of due diligence.

As seasoned IT guy, having two apps for my web, sound like so much problems I don’t want, thus a deal breaker for me.

Pimcore: an interesting proposal


This is a weird app, but if burn a few joints and think about the internal logic of it…. this could be the next big thing in open source e-commerce; time will tell.

For now I think is way too immature for physical products, but if you sell digital goods, you should really look into. And if you do implement it, please reach me, I’ll love to hear about your experience in ops.

But if you are in physical goods like me, just check it out, and keep an eye on it. And don’t get frustrated if you can’t get you head around it, is really weird.

For now, is my second best to Drupal Commerce 8. Thus in a year or so, will be time to compare these projects, as I currently (September 2015) estimate that upgrade should be done in first half of 2017.

Check out Pimcore here

Ubercart: The 80 MPH Max. Ferrari


I probably get dead threads from this, but come on Ubercart guys, you messenger pigeons and smoke signals do not scare me!

As Drupal users we love the diversity of the ecosystem, there are always many ways to achieve the same goal with Drupal. And for an online stores there is Ubercart and Drupal Commerce…

We must recognize Ubercart as the pioneer of e-commerce on Drupal, the project started on 2007 and has come long way, and is a serious alternative. It also have an active 8.x branch in development, so the project will not die in the short / medium term.

But here is the point: Ubercart is way more limited than Drupal Commerce, which could be sold as a feature of “simplicity” or “out the box”. And that will make sense if we were talking about almost any other CMS, but we all know Drupal has the slower learning curve of any CMS out there, and we still love it. Why? because it’s so powerful. Then why would you learn Drupal to only to do something simple? If you got a Ferrari, you better kick down the gas, or else just get a Volvo (and WordPress)!

The value proposal of Drupal is precisely on the complexity handling, so don’t waste you time and money learning and building a Drupal site, if you have not intend on putting to work for you it’s great capabilities.

For now I can think only one exception to this advice: If you already have a Drupal site, and you love it. And you need to sell products as side operation of the site, and you want a solution that expend less time possible, as you core business is in the other side of you site. Then, the Ubercart simplicity could be a smart choice for you.

Many of the fundamental differences come from the diferent origins; Ubercart 7 comes from a Drupal 6 port, and Drupal Commerce was entirely write from scratch for Drupal 7. Perhaps we should look for the same when the time to Drupal 8 upgrade comes.

If you still dubious about core differences, check this old post comparing Ubertcarb v/s Drupal Commerce, please bear in mind Drupal Commerce has come long way since 2011, but core differences and products as entities sections of that post still totally valid today (September 2015).

Drupal Commerce: The F1 Ferrari


I could write so many pages about its highlights, but I’ll try to keep it short. Let’s jump into the basics:

Product displays and products variants

There are products displays and products variants; Product variants are Drupal Entities where you should mirror your SKUs, if you sell a t-shirt in black or yellow at S, M and L sizes, then you will have 6 product variants. On the other side, product displays are nodes which references one or many product_variants, in this simple scenario you will add one product display for the “cotton t-shirt” referencing all previous products_variants, and Drupal will present the customer a page for the “Cotton t-shirt” where the user can choose size and color, thus and price, image will change on the fly, but also inventory check is done on a product variant base. Pretty neat, ah?

Customize, customize, customize

Do you remember the first point? Complex price schemas? No problem. Complex tax rules? No problem. What about micro-customizations? Time to use panels! How about implementing recurring payments? You may need to go PCI Compliance there!

At this point you need to work close with you developers, get them interiorized about you business model, your unique value propositions to customers and what set you apart from completion. Brainstorm about which features could you implement to add value to customers, to improve up-selling and cross-selling, to simplify business process (so you can have more time to grow you business instead of just operate it).

Make sure to implement this a permanent process, try to keep a recurring Skype or Zoom sessions with you devs, share a Google drive folder with ideas and references for future. If you have in-house developers, work to build strong bridges between them and the other departments of you organization.

If you are short of ideas for these brainstorms, here is a list of suggestions divided by the three cornerstones of e-commerce:

  • Increase visits
    • Commerce good relationships
    • SEO Image
    • SEO Videos
    • Automatic push content to SNs
    • Auto push products to Amazon and/or Google Products
    • Affiliates
  • Increase conversions
    • Setup GA events
    • Quality Search (search_api)
    • Testimonials
    • User submitted pictures
    • Q&A / Value content
    • Time constraint incentives
    • Ask how to give more visibility to your unique business propositions
    • Work on rich home-page
    • Products bundles
    • Auto shopping cart abandonment emails
  • Ask how to increase repeat business from same customers
    • Coupon inserts implementation
    • After buy review email request
    • Loyalty programs

Drupal Commerce for Drupal developers/builders

Building a properly done Drupal Commerce store is not a trivial task, as this post is intended for entrepreneurs. I don’t want to spend many words on dev advice, but if can only recommend one thing about Drupal Commerce for developers: not to use Commerce Kickstarter for real word projects. I know is extra work building from scratch at the beginning, but once you are operating you will value it.

If you are looking for out-of-boxness, look into Ubercart.

I have a Drupal Commerce guide for developers as draft, and I’ll link from here when is published, but I don’t know when will be. Check my general Drupal development workflow advice for now.

The bigger players

Even when this post was primarily written for entrepreneurs, you should know there are fancier enterprise alternatives too. From really pricey to crazy expensive: Insite, Demand Ware, Hybris and Oracle CX Commerce. We are talking about 6 to 7 digits in costs.

If you interested on that scale of solution, Drupal could still be you weapon of choise; here is a webminar where they talk about Drupal Commerce serving over 500.000 SKUs.

So be aware Drupal Commerce can be you ecommerce platform no matter if you are a garage startup or huge public traded company.

Learn more

I started this post explain you how important is for you to own this decision. So don’t just take my words on the issue, here are some suggestions to educate you further:

  • Check out this Oracle White Paper I think is half crap / half gold, but if you are smart you will get value the gold on it and ignore the crap (mostly corporate and enterprise points, come on guys: running a .net app is so not an advantage).
  • Install Appspector, which is small plugin that’ll show you on the browser bar, the technologyes behind the site you browsing, and start noticing in witch platform are made the stores you like.
  • Make a list of your favorites online stores against which you want to benchmark your own business, then try to focuses it to specific features: ¿Can you implement these features on your chosen platform? ¿How fast? ¿How expensive?

Let me know you story

Has helped this guide you to chose an e-commerce platform? Then please leave a comment below mentioning which app you chose and why. Are looking for a developer or consultant to build, improve or analyze your Drupal Commerce? I’m available for hire, so don’t hesitate to contact me.


Drupal development workflows: To yield returns, you need invest early

(Este post fue originalmente escrito en español)

Since the agile dev manifesto of 2001, it took force prioritizing functional software over extensive documentation. Under this priority, we got used to install a Drupal, download some modules, activate them and within hours have a working prototype from which would continue the development of our site.

But, how to keep the code in the future?

Eventually we will have many dozens of modules, it is not uncommon to have a hundred of them in a Drupal installation, especially in a commerce.

The issue about having unstructured code, is in the future, because implement changes will become complex and slow without breaking what is already done. This goes against one of the values ​​of the manifesto; The ability to respond to change.

But fear not, there are solutions.

In this article I will explain how to implement some techniques in your development workflow that although they are a little more initial work, in the long run it will save much time and hassle.

drush make: From many megas a few kilos

Drush is a Drupal tool that allows us to run multiple tasks through the command line interface (CLI), it is “the Swiss Army knife of Drupal.” One of its many features is the command drush make , it can create a code base “ready to use” downloading the Drupal core and modules from or git repositories, and even apply patches downloaded or local. In practical terms it is a way to distribute or store a complicated package of Drupal in a single text file.

For instance:

api = 2
core = 7.x
projects[drupal][version] = 7.38
; views module
projects[views][version] = 3.11
; bootstrap theme
projects[bootstrap][version] = 3.0

A make file like this, will download the core drupal 7.38, the views module 7.x-3.11 and bootstrap theme 7.x-3.0. Please notice the ability to add comments, allows us to explain to use each module or set of modules, when we have dozens of these, we can humanly navigate this file.

Features: From SQL php

The features module along with features_extra and Strongarm and allow us to “download” the settings from database to code.

Through drupal admin at /admin/structure/features, you can export individual components (views, contexts, CCK fields, rules, etc) to file set (feature), which practically acts as a standard drupal module, which you can use in any other Drupal, brand new or in operation, with the ability not only enable it, but also to update it or even reverse it.

The idea is to save functionality that you create through modules and configurations into features, thus making them truly independent of the database, relegating db to the role of mere content store and not functionality. Thus those features that you created, you can use them in different environments (local, dev, test, ops) and even in other projects, or other clients.

Do you begin to visualize how long can you win?

If it’s about agility, git gives you wings:

If you’re not using git yet at your development, pause all you developments, study it –I hear there are excellent tutorials at piratebay–, and implement git over you projects, in a week and you’ll thank me, really. If already git is you co-pilot, you can skip to next point.

Git is an application for version control, basically you set it up to monitor a directory that contains your source code that is called repository (in the simplest case would be your public_html). And on this directory, as you go making changes, run a commit command that kind of save of each revision.

The commit have a space for a title and a description, and although at first it may seem tedious and even a waste of time to write them, in time, when your project becomes complex –and especially when you have to do roll backs ( restore previous revisions)–, it will be extremely useful and will save a lot more work than it costed originally to write them.

Pro Tip:
Even if English is not you native language, in some projects is worth keeping the git comments, internal code and documentation in English, so you could integrate developers overseas to you proyect.

Another marvel of git is its branching function, which allows you to work in several parallel branches of the same project, allowing you to work parallel and independently in different functions or corrections to your code. When you’re satisfied with your work in branch, you perform a merge operation, which will integrate all changes from your side branch, your main branch.

The third key feature is git push, allows you to send your repository to a git server, which together with the pull command, which brings new changes to your computer from server, enable multiple developers to work in parallel in the same project. Bitbucket is my favorite free provider, Github is popular too but you must pay to have a private repository.

Finally, if you are someone who are intimidated the command interface, or simply does not suit you, I invite you to try graphical alternatives to git.

If you a mac user, let me recommend you Tower , in my case I use it because having a friendly graphical interface, I tend to write more and better messages on my commits.

Putting all together: Adapt to your hosting

In the simplest scenario, assuming you are in a classic hosting, using git is completely at your discretion and you have to discipline you self to run periodically git commits in your local environment. You should organize your work in at least two directories, one for the source and the other for the build. In the first you keep your project.make and you custom modules, themes and patches; the second will be “compile” your final drupal.

This task could be done manually, but is absurdly tedious. So at least I recommend you do a batch file that do for you each time, cleaning the build directory first, then running the drush make, and finally copying or creating symbolic links to your own modules and themes.

If you’re a friend of grunt, I recommend drupal-tasks; It is a plug-in to automate the build and testing of drupal, it even comes with a Yeoman generator that can do the initial project scaffolding for your. is a hosting platform that allows direct access via git and manage “up there” the commits and banching, generating independent copies of environments for each branching. If you already work in Pantheon, but you are not using these capabilities, my advice it checkout the Saul Willers slides on the topic exposed at June 2015 drupal Chile meet up.

In my current view has better rates and features than Pantheon, making it is my current favorite. In this scenario, once you have created your project through the web interface, you must download the Platform CLI (command line interface). Then executing a platform get, it will download the project and organize it into four directories:

  • builds: Stores the different builds that you generate.
  • repository: Stores your original source only.
  • shared: Stores drupal’s files directory and your settings.local.php
  • www: It’s a symbolic link to the latest build (for the convenience of your local web server).

Assuming you want to develop local you should create a settings.local.php file in your shared directory with at least your SQL credentials, like this:

// Database configuration.
$databases['default']['default'] = array(
'driver' = 'mysql',
'host' = 'localhost',
'username' = 'user',
'password' = 'pass',
'database' = 'db-name',
'prefix' = '',

And finally you need to configure your local web server to use www as the web root of your site, in this way it’ll always be on your latest build.

Now that you have everything set up, you must create a file project.make at you repocitory root directory. Platform will do the work for you then, either when making a local build trough platform build command at the project directory. Or when the build to run on their servers, which occurs every time you do a git push, Platform receives your source code and generates a build, deploying it in a unique environment.

If you like complications, you can highly customize the build in Platform to even compiling your sass or less on their servers to automatically when run a git push.

Pro Tip:
You can place a php.ini file in the root directory of your repository, to override Platform’s default.

In conclusion:

With a little more work in the initial setup of your workflow, you can get great savings of time in the future for a project, increasing your efficiency, speed and quality of response to you customer’s requirements.

Now you get this ideas, ask you self following questions:

  • Which of your Drupal projects could from experiencing these forms of work?
  • Which of your projects would benefit more if you implement these methods?
  • What will you do with the time that you win? Seriously, I invest it wisely. Time is the most valuable asset we have in finite human experience.

I invite you to share this post with your team or collaborators. And if you implement these methods, I would like to hear how it turn out, do not hesitate to contact me when you are 2 or 3 months using this methods.

Flujos de desarrollo en Drupal: Para ganar, primero hay que invertir!

(This post is also available in English)

Desde el manifiesto ágil del 2001, tomó fuerza el priorizar el software funcional sobre la documentación extensiva. Bajo esta priorización nos acostumbramos a instalar un Drupal, descargar módulos, activarlos y en pocas horas tener un prototipo funcional desde el que seguiríamos el desarrollo de nuestro sitio.

¿Cómo mantendremos ese código en el futuro?

Eventualmente nos encontraremos con varias docenas de módulos, no es extraño tener un centenar de ellos funcionando en una instalación de Drupal, especialmente un commerce.

El problema es que al tener tanto código desestructurado, en el futuro será complejo implementar cambios. Eso atenta contra otro de los valores del manifiesto; que es nuestra capacidad responder al cambio.

Pero hay soluciones.

En este articulo te explicaré como implementar algunas técnicas en tu flujo de desarrollo, que si bien nos costarán un poco más de trabajo inicial, en el largo plazo nos ahorrarán mucho tiempo y complicaciones.

drush make: De muchos de megas a pocos kilos

Drush es un complemento a Drupal que nos permite ejecutar múltiples tareas a través de la interfaz de comandos, es “la navaja Suiza de Drupal”. Una de sus multiples funcionalidades es el commando drush make, que puede crear una base de código “lista para usar” descargando el Drupal core y módulos desde o repositorios git, e incluso aplicarle patches descargados o locales. En términos prácticos es una forma de distribuir o almacenar un paquete complicado de Drupal en un solo archivo de texto.

Por ejemplo:

api = 2
core = 7.x
projects[drupal][version] = 7.38
; módulo views
projects[views][version] = 3.11
; theme bootstrap
projects[bootstrap][version] = 3.0

Un archivo make como este, descargará el drupal core 7.38, el módulo views 7.x-3.11 y el theme bootstrap 7.x-3.0, y la posibilidad de añadir comentarios nos permite explicar para que utilizamos cada módulo o conjunto de módulos, así cuando tengamos docenas de éstos, podremos navegar este archivo con facilidad.

Features: De SQL a php

Features2El módulo features junto strongarm y features_extra nos permiten “bajar” las configuraciones que están la base de datos, a código.

A través de una interfaz gráfica bajo /admin/structure/features podrás exportar distintos componentes (views, contextos, CCK fields, rules, etc) a conjunto de archivos (feature), él que prácticamente se comporta como un módulo más de drupal, que puedes usar en cualquier otro Drupal nuevo o en operaciones, con la posibilidad de no solo activarlo, sino también de actualizarlo o incluso revertirlo.

La idea es entonces ir guardando las funcionalidad que logras a través de módulos y configuraciones en features, haciéndolas así verdaderamente independientes de la base de datos, relegando el rol de ésta a un mero almacén de contenidos y no funcionalidades. De esta forma aquellas features que crées, las podrás usar en distintos entornos (local, dev, test, ops) e incluso en otros proyectos, hasta otros clientes.

¿Empiezas a visualizar cuánto tiempo puedes ganar?

Si se trata de agilidad, git te da alas:

Si aun no estas utilizando git en tu proceso de desarrollo, pausa todos los desarrollos que estés realizando, estudialo –dicen que en piratebay hay tutoriales excelentes– y luego retoma tus proyectos con git, a la semana ya me lo agradecerás, en serio. Si git ya es tu copiloto, te puedes saltar saltar este punto.

Git es una aplicación para realizar control de versiones, básicamente se configura para monitorear un directorio que contiene tu código fuente al que se le llama repositorio (en el caso más simple sería tu public_html). Y sobre este directorio, a medida que vas implementando cambios, ejecutas un commit que una especie de guardado de cada revisión.

Los commit tienen un espacio para un titulo y una descripción, y pese a que al principio te puede parecer tedioso e incluso una pérdida de tiempo completarlos, en el tiempo, cuando tu proyecto se vuelva complejo –y especialmente cuando tengas que hacer roll backs (restaurar revisiones previas)–, te será extremadamente útil y te ahorrará mucho más trabajo del que te cuesta escribir los títulos y eventuales descripciones de tus commit.

Tip Pro:
En algunos proyectos vale la pena llevar el git, los comentarios en código y documentación interna inglés, así podrás integrar desarrolladores overseas.

Otra de las maravilla de git, es su función de branching, que te permite trabajar varias ramas paralelas de tu mismo proyecto llamadas banches, permitiendo trabajar paralela e independientemente en distintas funcionalidades o correcciones a tu código. Cuando estés satisfecho con el trabajo en tu branch, realizás una operación llamada merge, que integrará todas las modificaciones de tu branch, a tu rama principal.

La tercera función clave de git es push, te permite enviar tu repositorio a un servidor de git, lo que en conjunto con el comando pull –que trae los cambios nuevos del servidor a tu computador–, hace posible el trabajo en paralelo de varios desarrolladores en un mismo proyecto. Bitbucket es mi proveedor gratuito favorito, Github es popular también pero debes pagar para tener un repositorio privado.

Por último, si eres de los que les intimida la interfaz de comandos, o simplemente no te acomoda, te invito a revisar las alternativas gráficas para git.

En mac específicamente te recomiendo Tower, en mi caso lo uso porque al tener una interfaz gráfica amistosa, tiendo a escribir más y mejores mensajes en mis commits.

Ensamblando todas las piezas: adaptate a tu hosting

En el escenario más simple, suponiendo que estas en un hosting clásico, el uso de git queda totalmente a tu discreción y tienes que ordenarte tu mismo en ejecutar commits periódicamente en tu entorno local. Deberías organizar tu trabajo en al menos dos directorios, un source y un build. En el primero mantendrás tu project.make y los módulos, themes y patches propios; en el segundo se “compilará” tu drupal operativo.

Esta tarea la podrías hacer manualmente, pero es absurdamente tedioso. Por lo que al menos te recomiendo hacer un archivo batch que la haga por ti, limpiando el directorio build primero, luego ejecutando el drush make, y finalmente copiando o creado vínculos simbólicos a tus módulos y themes propios.

Si eres amigo de grunt, te recomiendo drupal-tasks; es un plug-in para automatizar el build y testing de drupal, incluso viene tiene un generador Yeoman que puede hacer el scaffolding inicial del proyecto por ti. es una plataforma de hospedaje que te permite acceder directamente a través de git y gestionar “arriba” los banching y commits, generando copias independientes de cada entorno para cada branching. Si ya operas en Pantheon, pero no estas utilizando estas capacidades te recomiendo darle una miradas a las slides de Saul Willers en la junta de drupal Chile Junio 2015.

Para mi gusto tiene mejores tarifas y características que Pantheon, por lo que es mi favorito actual. En este caso, una vez hayas creado tu proyecto a través de la interfaz web, deberás bajarte el cli de Platform (interfaz por comandos). Luego ejecutando un platform get, éste descargará el proyecto y lo organizará en cuatro directorios:

  • builds: Almacena los distintos builds que generes.
  • repository: Almacena solo tu código fuente original.
  • shared: Almacena el directorio files de drupal y tu settings.local.php
  • www: Es un link simbólico al último build (para la comodidad de tu servidor web local).

Asumiendo que deseas desarrollar local, deberás crear un archivo settings.local.php en tu directorio shared con al menos los datos de tu SQL, algo así:

<?php // Database configuration.
$databases['default']['default'] = array(
  'driver' = 'mysql',
  'host' =  'localhost',
  'username' =  'user',
  'password' =  'pass',
  'database' =  'db-name',
  'prefix' =  '',

Y por último deberás configurar tu servidor web local para utilizar www como la raíz de tu sitio, de esta forma siempre estará trabajando sobre tu ultimo build.

Ahora que tienes todo configurado, debes crear un archivo project.make en la raíz de directorio repocitory. Platform hará el trabajo por ti, ya sea cuando hagas un build local a travéz del comando platform build desde el directorio del proyecto. O cuando se ejecute el build en sus servidores, lo que ocurre cada vez que realizas un git push; Platform recibe tu código fuente y genera un build, desplegandolo a un entorno único.

Si te gustan las complicaciones, puedes personalizar muchísimo el procedo de build en Platform, al punto de compilar tus less o sass en sus servidores automáticamente al realizar un git push.

Tip Pro:
Puedes poner un archivo php.ini en la raiz de tu directorio repocitory, para sobrescribir los valores por defecto de Platform.


Con un poco más de trabajo inicial en el setup de tu flujo de trabajo para un proyecto, puedes conseguir grandes ahorros de tiempo a futuro, incrementando tu eficiencia, velocidad y calidad en la respuesta a los requerimientos de tus clientes.

Ahora que entiendes como , te planteo las siguiente preguntas:

  • ¿Con cuál de tus proyectos Drupal podrías partir experimentando estas formas de trabajo?
  • ¿Cual de tus proyectos se beneficiaría más si implementas estas metodologías?
  • ¿Que harás con el tiempo que ganes? En serio, inviertelo con sabiduría. El tiempo es el activo finito más valioso que tenemos en la experiencia humana.

Te invito a compartir este post con tu equipo de trabajo o colaboradores. Y si implementas estas metodologías, me gustaría mucho oír como te resulto, no dudes en contactarme cuando lleves 2 o 3 meses utilizandolas y me cuentas.