Upgrade Your Drupal Skills

We trained 1,000+ Drupal Developers over the last decade.

See Advanced Courses NAH, I know Enough
Mar 13 2012
Mar 13

One of the unexpected challenges in raising money to grow your business is keeping mum about the deal until it's time. Time is likely among the many terms you'll find defined in your contract, and between the day you sign the papers and the day that time actually arrives, you're glowing inside because your investors believe in the potential of your business and want to see you do more.

Investors don't magically make a business plan succeed, nor do they single out the sole source of success behind a business or an idea. This is certainly the case with Commerce Guys' raise announced last week. We know for a fact that our investors get open source as much as they do eCommerce. Even as they evaluated us on our ability to execute our business plan, they evaluated us on how well we work within and alongside the larger Drupal community. When they took a close look, they saw the strengths of the community and the caliber of developers collaborating with us to build Drupal Commerce.

That's what makes it so exciting to share the news - investors and developers who have grown their own businesses and, in the case of the team at Open Ocean with MySQL, their own open source projects have looked closely into both Commerce Guys and Drupal Commerce and felt confident enough to front some serious cash for us to kick our efforts up a notch. Many of these guys have built their own eCommerce systems and understand the challenges we're in a unique position to solve through Drupal 7, Views, Rules, and Commerce, and they're guys who understand the importance of the community in the success of any open source project.

So, we're not crazy after all, and what we've been trying to build with our friends at Commerce Guys and in the Drupal community isn't crazy. Ambitious, sure, but achievable. Our vision for Drupal Commerce remains the same - to see Drupal Commerce become the world's leading open source eCommerce framework. For the last two and a half years, my time has been set aside by Commerce Guys to develop the code (with plenty of help from other brilliant Commerce Guys and community contributors) and grow the community needed to make it happen. Now we've sold the vision to some very smart people with deep pockets outside our normal circles and are eager to see what happens next.

Their affirmation is much appreciated, but so is the money that will let us hire and set aside even more developers to "scale me" out a bit. We need to address immediate concerns pertaining to documentation and community support on DrupalCommerce.org. We'll need to make sure we follow-through on our longstanding 2.x strategy to bring some sanity to the user experience for administrators even as 1.x has privileged developers. All the while, there will be more than enough module maintenance and distribution work to go around!

Addressing these needs for Drupal Commerce should only require a fraction of the money we've raised, but it's a good start that will have an immediate positive impact on the thousands of people already using Drupal Commerce to power their online businesses. If you think you can stomach working with me on a daily basis and have the chops to help us succeed, be sure to get in touch.

Jan 24 2012
Jan 24

One of the things I'll miss about Louisville, KY when I move my family to Greenville, SC next month is the buying club we're a part of that sources raw / organic foods and other products from local farms and other good companies. It was put together by a genius I knew through college and church (John Moody, who writes and speaks about food clubs and co-ops), and last year another college buddy (Kane Holbrook) started working with him to help manage the club and oversee deliveries and pick-ups. Among the many yummy things we get through the club are a variety of raw milk cheeses from Welsh Mountain Farms, an Amish farm in Lancaster County, Pennsylvania.

It just so happens that this farmer, yea, though he has no internet access himself, understands the advantages of selling online and asked Kane last year about starting a website to sell his cheese. Kane floated the idea by me, and it quickly became a business plan and partnership to start selling his cheese using Drupal Commerce. Not only did it help the farmer and open a door for Kane and I to do some business together, but it also finally gave me a chance to experience using Drupal Commerce as a site owner and administrator. After two years of planning and development, I finally started eating my own dog food when we launched RealMilkCheese.com in November.

I'll have more to write about the site in the future, as I learned a lot through it and contributed a lot of code from the project to drupal.org. It became the driving factor behind my development of the flat rate shipping module and UI improvements for on-site order management in Drupal Commerce 1.2. It's also the primary example I use to demonstrate multiple flat rate shipping options with conditional availability (think free shipping on orders over a certain amount) and custom discounts to products through an integration with quicksketch's Facebook OAuth module. It was my second foray into theming with Omega and turned up a few tips that I need to pass on to other theme developers with respect to Drupal Commerce components. Finally, it gave me my first experience launching a site on Acquia Dev Cloud using one of those handy coupons they give out at Drupal events.

But the primary purpose for this blog post is to highlight one specific difficulty we encountered while administering orders and the simple solution I put in place to resolve it. In Drupal Commerce, the shopping cart is simply an order in a special status that indicates it's "in progress" and therefore needs to be continually updated to reflect current product prices and availability. By default an authenticated shopping cart order (i.e. for a logged in user) may exist indefinitely until the user finally completes checkout for the order. (There's an issue to expire them through Rules if you're interested in reviewing it. )

We encountered a scenario where a customer added a product to his shopping cart the first week of December but didn't actually purchase the cheese until we sent out a special offer over the holidays for a free 8 oz. cheddar for orders placed in a certain timeframe. It was great to see the immediate effectiveness of the offer (recovered cart sales are a big deal), but because the Orders View on the back-end sorted orders in reverse order by creation timestamp, his order appeared down the page below orders that had already been shipped and marked as Completed. It's not a huge problem, because a filter on the View to only show Pending orders by default would highlight orders needing attention, but it still isn't an ideal user experience.

The thought occurred to me that for our scenario, it would be fine for the creation timestamp of an order to be reset to the current timestamp on checkout completion. As far as we're concerned, that's when an order has been "created" that we actually need to respond to. It actually existed before then, and we'll retain that data in the order's revision log, but we really want to know when the order was finally submitted through a complete checkout process. I started imagining where I would put code to do this when I realized I wouldn't do that at all... a simple Rule would do the trick!

This Rule reacts to the event "Completing the checkout process" and includes a single "Set a data value" action to update the created timestamp to the current time. Because every order save triggers a new revision, we'll have the historical creation date if we want it, but the date that matters to the customer and to administrators (i.e. the date of checkout completion) will now appear properly. If you need the same behavior, you can import the following Rule:

{ "rules_update_the_created_timestamp_to_now" : {
    "LABEL" : "Update the created timestamp to now",
    "PLUGIN" : "reaction rule",
    "REQUIRES" : [ "rules", "commerce_checkout" ],
    "ON" : [ "commerce_checkout_complete" ],
    "DO" : [
      { "data_set" : { "data" : [ "commerce-order:created" ], "value" : "now" } }
    ]
  }
}

Now, I should be used to the level of flexibility we achieved in Drupal Commerce by now, but it still tickles me to no end that it really is that simple to change even obscure aspects of your e-commerce system through the user interface. When I communicate the strengths of the project as an eCommerce framework, concrete examples like this make the approach come to life for merchants and store administrators. It's a clear case of the software conforming to your business needs instead of forcing you to work within its constraints, and I look forward to seeing how else we can trick it out to grow our little cheese business.

Jan 22 2012
Jan 22

It's no secret that I love to travel (in appropriate doses) and meet new people, especially those doing e-commerce on Drupal. I love visiting the larger cities in the States, and I love even more visiting the older cities in Europe. Fortunately for me, these are the places that draw large Drupal events and make the most sense for Commerce Guys to put on Drupal Commerce trainings.

I'm currently wrapping up the final commits for a Drupal Commerce 1.2 release this week and will then start revising our training curriculum to accommodate a few recent UI improvements. Drupal Commerce is growing in popularity as an e-commerce framework, particularly among tech savvy developers and organizations (we still need to cater better to those with limited resources and Drupal skills), highlighting the need for better "self-help" documentation and resources and the continued need for personal training from expert users and developers.

I'll be involved in a couple of trainings in the next couple of months, and I hope there will be even more that I don't have to attend. (Unless of course they're in cities that are too good to pass up. )

If you have a project about to start or have recently been handed a site to maintain, consider one of these upcoming opportunities:


  • Paris is both my favorite city to visit and home to my favorite company to work for - what luck! We'll be presenting a three day developer training including personal instruction from myself and a few other members of our team. As my French knowledge goes about as far as a 1 year old's, and since we're expecting attendees from a variety of countries, rest assured this training is in English.

  • This will be our regular one day extravaganza where we introduce all that Drupal Commerce can do for you and demonstrate how to build a store using the core components and a few essential contributed modules. We'll provide a sandbox server so you can follow along and take your site with you when you go.

I've also recently put in work with Kent Bye of Lullabot to turn that one day course into a video series for Drupalize.me. We basically put down about four hours of video demonstrating how to build a site like my RealMilkCheese.com - no code required for a simple catalog, payment via PayPal, flat rate shipping, and a couple types of discounts. I'm looking forward to seeing it edited to a fine polish - Kent's a star at that stuff.

Sep 27 2011
Sep 27

In Drupal Commerce, a line item is any item added to an order that affects the order total. They represent products, shipping rates, certain types of discounts, and more. During sell price calculation for products and rate calculation for shipping, you actually apply discounts, fees, and tax rates as manipulations to the unit price of line items.

I've been dealing a lot with line items during a personal shipping sprint I've been on the last week and a half to help launch a client site. That work has involved a complete rewrite of Commerce Shipping in the 2.x branch to support carrier calculated rates (such as those returned by ConnectShip, UPS, FedEx, etc.). That work in turn has resulted in the release of a Physical Fields module that defines weight and dimensions fields and a Commerce Physical Product module that provides API support for determining when orders contain shippable products, the total weight of the order, and other useful things.

Once this site launches, I'll give more attention to the upgrade path for folks using Shipping 1.x to move up to Shipping 2.x. (I'll also need to rewrite the flat rate shipping method to go along with it.) To push forward integration with different carriers, we'll be holding a Shipping Sprint at DrupalCamp Atlanta, fittingly the corporate home of UPS.

During the course of my work on Commerce Physical Product, I was reminded that determining whether or not a line item represents a product isn't as straightforward as you would first think. It's nothing terribly tricky, but you can't just perform a simple check on the product type to reliably determine if a line item represents a product.

This is insufficient:

<?php
if ($line_item->type == 'product') {
 
// ...
}
?>

The reason is Drupal Commerce allows you to have multiple product line item types, each with their own unique fields that may be exposed through the Add to Cart form. This feature lets you sell customizable products where the various customizations are stored with the product reference in the line item.

A simple use case is adding a custom price field to a donation product line item type allowing customers to tell you how much they want to donate to a specific campaign. This can all be configured through the Field UI and Rules, mitigating the need for modules like UC Variable Price. Trés cool.

Since you can have multiple product line item types, we provide a helper function that returns an array of the names of every product line item type defined on the site. Instead of the code above, you can perform an in_array() check on the type of a line item to see if it is of any of the valid product line item types:

<?php
if (in_array($line_item->type, commerce_product_line_item_types())) {
 
// ...
}
?>

Any time you're writing code that should apply to a product line item, be sure to use this method instead of the first. Hope that helps you as you work on your Drupal Commerce contribs and custom modules. I almost forgot about this when writing Commerce Physical Product. Granted, I haven't been sleeping much recently, but if it's that easy for me to forget, I bet it's a bit unknown to the general public.

Sep 06 2011
Sep 06

One of the best things you can do for your project is highlight the contributors who are helping make it a success. Every patch counts, and every now and then you get someone in the queue who blows you away with a first patch that traces down some sneaky, hidden bug that you know took hours to track down. Attributing such patches has always been a matter of dropping the contributor's name into a commit message and thanking them in the issue in the past, but thanks to Git on drupal.org there is now a better way.

This may be old news for most folks, but I didn't discover this feature until just a couple months ago. It turns out that user profiles on drupal.org now include a Git attribution heading under which you can find the appropriate command line option to pass to git commit to attribute that user with a patch.

Attributing svendecabooter

By way of example, I recently committed a patch submitted by svendecabooter. I still formed my commit message using the tried and true format (including both the issue number and his username), but I also added the indicated text to the command:

git commit --author="svendecabooter <[email protected]>" -m "Issue #1197512 by svendecabooter: pass the entity rendering language down to the linked fields when rendering product fields."

Thanks to Git, even though I am the one committing the code, he is the one credited with authorship of it. This is visible both in the log for that commit and on the committers page for Drupal Commerce. Many thanks to the team for working this all out and helping maintainers give credit where credit is due.

Sep 01 2011
Sep 01

As it turns out, I really enjoyed my time in London. Getting to visit old, historic cities is quite a treat for someone from the Midwest in the U.S.A. There are no castle towers on hills or centuries old steeples gracing my skyline in Louisville, KY, and I'm quite a sucker for both. Getting to visit the Tower of London, which supplies arms to my local museum, turned out to be a special treat. I'm also a sucker for good food and drink (who isn't?), and while it's not the height of elegance, my first experience of fish and chips with mushy peas was good, too. Note to Americans: it's mush-y, not moosh-y.

Fish and chips with mushy peas. Mmm!
Fish and chips courtesy of The George.

My first couple of days in London were my busiest. I delivered a Drupal Commerce training to a room full of students with Greg Beuthin (a.k.a. smokinggoat), our in-house trainer par excellence. Unfortunately, he and I both had sniffles and scratchy throats, so I can only imagine what those reviews will say about our delivery... C'est la vie. We survived, but my day was only just getting started by the end.

For most of the next day and a half I was minding my queue in preparation for the 1.0 launch of Drupal Commerce. With the help of Bojan Zivanovic and Damien Tournoud (and a few others throughout the day), we were able to close out a variety of issues and ensure all of our automated tests were passing when we finally packaged the 1.0. In a feat of endurance sure to be remembered for ages to come, Damien and I outlasted Bojan's youthful energy to finalize the release after postponing dinner for a couple hours. That's what experience gets you, folks.

Excited Damien

An excited Damien is never too hungry to celebrate.

Proud father

It's a boy! He weighs 8 lbs. 6 oz. and is 22" long!

Coming to DrupalCon to collaborate with the other Commerce Guys and the various contributors from across Europe was the greatest part for me. Without the community, we wouldn't have the 1.0 that we do, a solid e-commerce framework that is not limited to a particular use case or locality. We're standing on the shoulders of Drupal core, the contributions of Merfago, and the dozens of patch contributors who have helped ensure Commerce can accommodate all those crazy taxes around the world. I also personally wouldn't have known that mushy peas are better with malt vinegar mixed in without John Albin Wilkins.

With the 1.0 out, my attention is now focused on ensuring our essential contributed modules are ready for use. I'm focusing specifically on making product administration simpler, ensuring Commerce Shipping supports calculated shipping quotes, and pushing code upstream from a local project into Commerce Addressbook. I always have a half dozen payment related projects in the works, too.

If you want to hear more about Drupal Commerce in person, I'll be talking about the project as an international community success story at DrupalCamp Atlanta. I'm busy compiling statistics on committers and contributions to share along with my usual hand-waving, mile-a-minute overview of the modules' functionality.

I'll also deliver a show-and-tell style training at this year's Do It With Drupal in NYC. I love DIWD as a more intimate gathering of module authors, core contributors, and web pros from outside the Drupal community. It's a great place for attendees to soak in a wealth of information and run their project needs by the folks writing the code they'll use. Today is the last day for early bird pricing, so if you're on the fence, you may as well make the impulse buy and come hang out in New York with us.

I hope to see many of you at those events and many more minding the queues.

Aug 21 2011
Aug 21

At long last I'm breathing British air and getting psyched for tomorrow's Drupal Commerce training. I lived in the UK for four years as a child but only have vague memories of a nanny and getting AG Bear and My Buddy for Christmas. I didn't come back with a nanny, but I did bring along my wife to help take care of me and my daughter to carry the dolls. We spent a few days in Paris recovering from jetlag, ringing in our fifth year of marriage, and finalizing training arrangements before riding the Eurostar to London with the rest of the team this afternoon.

We'll have a total of fourteen Commerce Guys at DrupalCon London, meaning we'll have plenty of people on hand to talk about Drupal Commerce. In addition to tomorrow's training, we'll be presenting / discussing the Commerce modules and contribs in BoF sessions throughout the week. To see the line-up, check the BoF schedule under Room 334. If we can record or screen capture anything from these, they'll end up on the Commerce Guys Vimeo channel.

I'm looking forward to the Developing with Drupal Commerce session on Thursday, because it will be me first go at leading a panel discussion instead of introducing all things Drupal Commerce in a solo, hand-waving, water-guzzling presentation.

I'll be joined by several other developers and business owners who have been bidding on and building Drupal Commerce sites since the alpha and beta releases. We're now gearing up for a 1.0 release thanks to the hard work and contributions of everyone on the panel. It should be valuable and entertaining to hear them talk about what it's like to develop with Drupal Commerce and how the core modules have evolved since they've been working with them.

Last but not least, for everyone who doesn't care a lick about e-commerce but likes Indian food, I have discovered the best Indian place in Croydon. Look no further than The Spicy Affair for a fair-priced, keenly seasoned meal (with a surprisingly kid friendly wait staff!). That's probably the most controversial statement I made in this blog post, and I can't defend it as though I'm some sort of connoisseur. If you know a better place, feel free to link it in. Otherwise I'll see you there.

Jun 25 2011
Jun 25

As part of the sprint we're holding in Paris right now to introduce new Commerce Guys to Drupal Commerce development, we devised a situation where we wanted a conditionally available message on the checkout form. We decided for a shipping scenario that we wanted to present a message to the user regarding shipping costs inline with the address form if the customer selected a shipping address outside of the free shipping country of the store.

Adding a random text message to a form is trivial. You can just add a markup element to the form, using a div tag to make sure it ends up in a fieldset if necessary:

<?php
$form
['message'] = array(
 
'#markup' => t('What a wonderful message!'),
);
?>

Additionally, adding a #states array that includes the instruction to hide a form element on the basis of a select list's value is trivial:

<?php
$form
['message'] = array(
 
'#markup' => t('What a wonderful message!'),
 
'#states' => array(
   
'invisible' => array(
     
':input[name="select_list_name"]' => array('value' => 'US'),
    ),
  ),
);
?>

Unless I botched my pseudo code, that #states array should instruct the Form API to include JavaScript to hide the element when the select list I specified has a value of US. Unfortunately, that code won't work. Shocked

The problem is that the JavaScript that hides the element depends on the element's ID to target the behavior, and a markup element by default gets no wrapping. This means you can't directly put a #states array on a markup element in general. You do have a few options to work around this, and I'll end with what we went with in our case... you can tell me if we're crazy. Sticking out tongue

  1. You could just hardcode a div wrapper that includes the ID and the form-wrapper class Drupal expects, but I can't say that I'd recommend it. Names change quite frequently during development and can easily be altered.
  2. You can also just put the markup element inside a container element and attach the #states array to the container. Containers are rendered as divs with proper IDs for targeting, so this works just fine.
  3. However, we wanted a compact solution, so what we did is turn the markup element into a container element and set its #children property to the message. This effectively makes the container element function as a markup element, but it actually wraps the markup in the appropriate div on output. Since #children is already set, this does mean that the container element cannot actually contain other elements, so there may be good reasons for you not to try this at home.

The gist of our solution was:

<?php
$form
['message'] = array(
 
'#type' => 'container',
 
'#children' => t('What a wonderful message!'),
 
'#states' => array(
   
'invisible' => array(
     
':input[name="select_list_name"]' => array('value' => 'US'),
    ),
  ),
);
?>

I suppose it would be nice if we didn't have to abuse the #children property name, but this seems like fair game to me unless it's a possibility to change the markup element to include the div and expected ID.

Mar 01 2011
Mar 01

Because we were doing our Commerce module development on GitHub and exporting to CVS, we need to make some changes now that the Git migration on d.o is complete. Obviously the main Git repository for the project is now on d.o instead of GitHub. To clone the latest code, you can follow the helpful Git instructions included on Drupal project pages.

All of my D7 projects now include a 7.x-1.x branch that you should track to get the latest commits. I also updated the various dev releases of Commerce, Address Field, and my Commerce contribs to be snapshots of this branch, essentially deprecating master. I'm trying to decide the best thing to do about those pesky master branches and will likely just git rm everything in them and leave behind a README indexing the various HEADs in the repository.

Many people had forks of both the old Commerce repository and my development repository on GitHub. Additionally, some of you may have pending commits that haven't been pulled yet. If this is the case for you, please generate a patch instead of a new pull request and post it to the issue queue. As of this point I have no plans to rewrite the commit history of the new official repository to match the existing history on GitHub, meaning I cannot cleanly pull from your repositories.

(I have read Ben's blog post, and I'm sure there are some other finer aspects of Git that I'm just ignorant of to accommodate this... but I'm not sure it's worth the hassle when forks will need to be updated across the board anyways.)

This seems a little brute force, but I think it's for the best. The commit graph on d.o is now a nice tidy straight line, whereas the old graph on GitHub was a fractured mess that included several instances of duplicated commits thanks to botched merges and branching. We were still learning an appropriate Git workflow at the time and made several mistakes that not only dirtied up the history but also made it hard to sort out how to pull from various forks. (Accordingly, current contributor statistics on Ohloh are inaccurate anyways.)

This does mean some contributor credit in the commits will be lost, but I'll be updating various project pages to credit beta contributors for their commits. Regardless, I've been crediting contributors in commit messages all along, and merge commits show whose repository the merged commits came from. As of this point, I think the loss of a little meta information is worth the clean slate with the new repositories. Flame away in the comments if this is the stupidest idea you've ever heard... just want to make sure my plans are clear.

While we figure out how to handle pull requests in an environment that doesn't natively support them, in your issue please indicate your repository URL (whether it's a d.o sandbox of GitHub fork) and branch that I should pull from to compare. Bonus points for attaching a patch for quick review on site (or linking to the diff on the appropriate web interface). I'll add your repository as a remote so you don't have to post it every time. Additionally, I'd prefer it if you used a single branch per issue you're addressing with the branch name simply being the nid of the issue - makes it quite easy for me to branch and pull locally.

(I should mention that the good ol' patch process is perfectly fine if you don't want to maintain a public repository for me to pull from. You can just make your commits locally and diff 'em all in one fell swoop to create a patch for review.)

This is essentially what we've been doing on GitHub, so no surprises here for existing contributors. I'll leave the GitHub repos up for a while, but I'm updating their READMEs to point to the new repository on d.o. Once tested and approved, these guidelines will find their way into a handbook page for posterity's sake.

Feb 23 2011
Feb 23

This is a quick call for help before I package up a beta release of Drupal Commerce. The last few weeks I've been working around the clock on blocking issues, dependency issues, Rules based pricing and tax (incl. VAT) support, and last minute database tweaks. My wife has been incredibly supportive of me thus far, but now I need help from my friends with a bit more technical acumen.

Here's the deal: for all intents and purposes, this code is beta ready. Database schema changes have mellowed out. The modules have solidified. The core feature set lets you start selling quickly. The Views and Rules integration provides for some fine standard interfaces and workflows. The last few weeks, pcambra has been our SimpleTest hero, and now he's working with recidive to flesh out the functional tests even further.

What it really needs is eyes. Your eyes. If you have a few spare moments, you could greatly help by testing an installation and ensuring there aren't any crazy bugs that I just don't see because of my development environment or selective blindness. These could take the form of installation bugs, odd default configurations in Views / Rules, typos, broken access control, and more. There are bound to be things I'm missing, and I really need your help to know what they are.

Here's how to get started very quickly:

  1. Download into your sites/all/modules directory the latest dev versions of the following dependencies:
    1. (Note: Getting these from CVS would be better to get their latest commits.)

    2. Download into your sites/all/modules directory my Git dev version of Drupal Commerce (or just git clone git://github.com/rszrama/drupalcommerce.git).
    3. Download into your profiles directory my Commerce Dev installation profile and download into your sites/all/modules directory Admin Menu (a dependency of the installation profile).
    4. Now install Drupal 7 using the Commerce Dev installation profile and see what happens!
    5. If you're feeling adventurous, use the Standard installation profile and then try to enable the Commerce modules manually to make sure the standard install process works. (You'll have to adjust some permissions, enable the cart block, and build a product display node type from scratch - read more about that in the first issue of Drupal Watchdog. )

    Once it's all installed, cruise through the various admin interfaces, settings forms, and front end features and let me know what breaks. Note, I'm not looking for support requests, "How do I...?", or feature requests, "Needs flat rate shipping support." Rather, I want to know what, if anything, of the core feature set just doesn't work.™

    One of the latest features to test will be to configure a tax rate for your country / state. Simply browse to admin/commerce/config/taxes and add the tax rate. If you made it a sales tax, it'll show up once you get to checkout. If you made it a VAT, it'll show up inclusive in product prices. Additionally, if you made it a VAT, you can edit products and enter their prices including VAT. Taxes work through the same Rules event as other product pricing rules, so you can try adding a discount rule and fiddle with its weight to see how it interplays with your tax rules.

    Drupal Commerce comes with an example payment method module that lets you just put a name in on the checkout form to test payment. You can test additional payment methods if you have developer accounts for Authorize.Net, CyberSource, or PayPal.

    Please report any bugs you can turn up (or +1 existing bugs) in our issue tracker. I'll also be hanging out in #drupalcommerce on irc.freenode.net if you're into IRC.

    While you do this, I'll be running tests of my own, reviewing the names and descriptions of all our permissions, and ensuring the customer profile integration with Checkout and Order administration is up to snuff.

    With any luck, we'll all be beta testers tomorrow.

    Jan 28 2011
    Jan 28

    I started to answer this question with a discussion of my own motivations for module development. They are many and varied, but they pretty much all come down to me either having an idea and some time or me getting paid to make time for an idea. However, I realize a person's motivations for writing his or her intangible "Drupal App" don't really matter if a particular motivation can co-exist with the existing model of community module development (whether it's evil or not, ignored or not, mirrored or not)... and ultimately I didn't want to do Robert's problem solving for him on what that could look like.

    I then decided to take the angle of problems with the architecture of Drupal modules vs. an App store model, current support and maintenance channels, and a host of other problems I see with the idea of Drupal apps. Some points were established elsewhere... Yes, we can't really sell modules. Yes, people are selling themes. But no, I don't think selling "Features" would work... or at least I don't think it would be good for the consumer.

    The traditional "App" (I hate that word - really? are we selling full applications?) must encapsulate its functionality, and it can't be effectively supported if its innards are free to be customized and mixed in with (i.e. broken by) other modules. This lack of interoperability between paid plugins on other platforms was actually quite a shock to me at last year's CMS Expo and is a big weakness. It also increases the development burden on the "App developer" making it a net loss for the consumer and provider. (Really, I saw an e-commerce plugin baking in its own Views system.) In fact, the only person I see getting a good deal is the "App distributor."

    But I digress... these are just software / social engineering problems. If distributors really wanted developers and consumers to buy into their distribution models, they just have to provide solutions for these things. Once again, I'm not trying to do anyone's problem solving... unless they want to cut me in on their good deal.

    What an App Store won't solve

    I think other threads of this conversation have been dealt with adequately elsewhere, and overall I think an App store could work if all caveats are accounted for and the store's success is mitigated enough by the strengths of drupal.org to not blast holes in the community development model we currently have. One thing I don't see getting a lot of play in the discussion, though, is whose problems an App store wouldn't solve. I've been thinking about this since taking part in the discussion with ICanLocalize (sorry, can't find the link).

    A paid distribution channel will not provide you with the time or money to code or support your module. You still have to make the initial investment in time or money to get your "App" written, and long before you're turning a profit you'll need to be proving your intent and ability to support your product. If you then rely solely on distribution fees to recover your investment, you're relying on the wroooong license to get 'er done. If you intend to bundle support and maintenance with the distribution, I just need to point out again... this is first and foremost a good deal for the distributor unless he turns your App into Angry Birds.

    Really, though, this is freaking Drupal... all we need is for enough interested people to build an installation profile for paid module support. Does that mean every module's support would go behind a paywall? I sincerely doubt it, as again, developers still have to prove their competence to support their project to non-paying new customers to convert them in the first place. They're also not the only ones who support modules on d.o... every one of their users is a potential support provider.

    I do think that publicizing intentionally scaled back support in the absence of a paid distribution channel is not a good way to win hearts and minds. You don't have to say it, just do what you need to make money and offer premium support for people willing to pay for it. There are also other ways to build support around your module in the community, whether it's a bug squad or a sponsored development sprint.

    Leaving module developers behind

    Finally, something that just hit me... the only "Apps" I see as being viable at present are SaaS plugins and themes (thanks to licensing opportunities). Others see distributions and Features-esque configurations as viable. Perhaps there are still other viable options, but at the end of the day, none of this translates into dollars to fund the module development that any of these products depends on. And isn't that what started the conversation in the first place? Are we trying to figure out how to support module developers, or are we looking for a different way to make money using Drupal + contributed modules beyond professional services?

    About Drupal Sun

    Drupal Sun is an Evolving Web project. It allows you to:

    • Do full-text search on all the articles in Drupal Planet (thanks to Apache Solr)
    • Facet based on tags, author, or feed
    • Flip through articles quickly (with j/k or arrow keys) to find what you're interested in
    • View the entire article text inline, or in the context of the site where it was created

    See the blog post at Evolving Web

    Evolving Web