November 8, 2009
This is the second in a series of posts outlining the ideas driving the Ubercore Initiative forward. We've had a lot of positive feedback from developers eager to dig into Drupal 7 to re-implement Ubercart's features like the awesome vision of products outlined below.
For starters, when we gathered for the Ubercore planning sprint in San Francisco, we began by nailing down the core systems without which we wouldn't have an e-commerce system and which we needed to build out other essential features. The links above are our whiteboard scribblings based on Ubercart's current features, but the one we gave the most time to was the core product system. The resultant notes and discussion summarized in this post may be viewed here.
In short... it's gonna be awesome, and it's all thanks to Drupal 7's Fields API. Products are already great in Ubercart, but as one person recently tweeted, the implementation thus far has been a little awkward. Furthermore, from a data standpoint, it's been quite limiting.
How about a visual? It's my first go at Omnigraffle...
Currently, Ubercart defines a new product node type on install and gives you the opportunity to clone multiple new product node types called "product classes." These can then have default attributes assigned to them, which are customer selectable alterations to products at the point of purchase. For example, your merchandise store can have a t-shirt product class with a size attribute attached to it that your customers choose when adding the shirt to the cart. Each of these attributes can result in a price, weight, or SKU adjustment as well. There are also multiple product types defined at the module level, so that regular products function differently from product kits, each having their own add to cart form and functionality in the cart.
Problems come in you try to define just what a product is. Is it a node? Well, with SKU adjustments, aren't more than one products visible on a single node? How does Ubercart know those altered SKUs exist? There are implications here adversely affecting the development of stock control systems, sales and product reports, the shopping cart and order product handling, representing non-tangible products, and more. Happily, we have a plan we think will address these shortcomings without losing any of our current features.
So, what is the future of products? As fago hinted in his post, the future of products is entities, not nodes. We're separating "what a product is" from "how a product is displayed" and making products themselves top level, fieldable entities. Thanks to bundles, we'll still have multiple product types with various attributes, but instead of the current system where attributes are very loosely defined, we'll be moving more toward a product database where each individual product is defined and described by fields you add. Whereas before you might have had a single t-shirt product node with three variations thanks to a size attribute, you would now define a t-shirt product bundle and enter in the three variations with their SKUs and sizes set.
To handle product display, we'll be using a field that lets you specify which products to show on whatever the field is attached to (like a product display node) and how to prepare them for display. The products selected might all be listed individually for the user to select from a radio list. They might be grouped on their size field so that a size select list appears on the add to cart form as it does now. They might be sold all together at a set price as a product kit. We want this product display field to be flexible and to correct the difficulties people have in working with the current add to cart form.
This approach will clarify what a product is (a bundle of fields, including at least a SKU and a default title / price) and provide greater flexibility in how it is displayed (contributed field formatters, anyone?). Modules working with the product system, like stock control modules, will now have a unique product ID to refer to instead of a node ID with an array of attribute selections. We'll have better Views integration and end up with a product entry field that could attach an add to cart form to any entity.
Honestly, I could go on, but I'll stop here. This is already more gushing than I was planning to include in a single post. If you want to read more, hear what other people are thinking, and provide some feedback, you can check out the brainstorming thread, comment here, or keep an eye on the fieldable product meta issue as we flesh out the development tasks.
If you want to help make it happen, don't be shy.
November 8, 2009
Top Notch Themes released the first beta of Fusion recently, a base theme that works in conjunction with the Skinr module to fulfill their vision for the future of theming and theme configuration for Drupal. They even have a theme in development that takes full advantage of the new base theme called Acquia Prosper that pretties up your site for selling stuff with Ubercart... in my opinion, their best theme on d.o to date.
However, I'm not just writing to share the good news about their release. In conjunction with their work, I have a little fun development of my own to share.
Friday evening, I buckled down to do something I'd been needing to do for a while... I updated the UberDrupal installation profile to install and configure Acquia Prosper out of the box. With that profile, you can have a functioning Drupal store in no time flat that even integrates with the sharpest contributed theme for the task! There are several modules and themes you have to have on hand before running installation, and I'll be writing those up and presenting how to use it at DrupalCamp Austin and Do It With Drupal in the next month.
Those interested in the future of Ubercart on Drupal 7 and beyond may have heard of the Ubercore Initiative. This recent development on UberDrupal was motivated in part by our goals for d7uc of improving the "packaging" aspect of what Ubercart is. We're looking to address the split personality of Ubercart as a component module vs. a ready-to-use e-commerce application. Right now, the project suffers from a lack of focus in the component module space, having incomplete Views support (requiring even a separate project to get the job done) and little integration with other major contributed modules (product image support notwithstanding). In the application space, it is limited in that there's only so much you can do through hook_install() and hook_enable(). We're hoping a bit of clarification and planning can improve it in both these areas to make Drupal the best e-commerce platform on the web.
This post will be the start of a mini-series with aggregate thoughts gathered from my notebooks, d7uc conversations, and chats on how we can improve Ubercart in the future through d7uc. I'll try to keep them short and to the point and toss in some pretty pictures and diagrams. There's been a LOT of good brainstorming so far, and I can't wait to make these plans a reality.
The future is bright.
October 24, 2009
I've blogged before about what it means for a Christian to fear God, especially in conjunction with my thoughts on 1 Peter 1:17, "And if you call on him as Father who judges impartially according to each one's deeds, conduct yourselves with fear throughout the time of your exile." Christians differ on what it means to fear the Lord, and non-Christians generally question both the need and propriety of such a doctrine in respect to a loving God.
I found some unexpected wisdom to this point in a letter by Jonathan Edwards. The quote below comes from a discussion on Christian assurance in relation to the shortcomings of the first Great Awakening:
"And I am persuaded we shall generally be sensible, before long, that we run too fast when we endeavor by our positive determinations to banish all fears of damnation from the minds of men, though they may be true saints, if they are not such as are eminently humble and mortified, and (what the Apostle calls) "rooted and grounded in love" [Ephesians 3:17]. It seems to be running before the Spirit of God. God by his Spirit does not give assurance any other way, than by advancing these things in the soul. He does not wholly cast out fear, the legal principle, but by advancing and filling the soul full of love, the evangelical principle. When love is low in the true saints, they need the fear of hell to deter them from sin, and engage them to exactness in their walk, and stir them up to seek heaven. But when love is high, and the soul full of it, we don't need fear. And therefore a wise God has so ordered it that love and fear should rise and fall like the scales of a balance."
In other words, such fear isn't meant to last. It's a condescension, a means of preservation for the believer until he attains such a maturity in his love for God that he needs no other impetus to persevere in the faith to the end of his days.
John Piper recently posted another link to an Edwards quote that was foundational for him in the formulation of what he calls "Christian hedonism." He pulls a lot from Edwards, Lewis, and a myriad of other respected, historical theologians. This particular link is to a paragraph explaining the way that our delight in God is the climax of our glorifying God. Check it out and check out C.S. Lewis' sermon "The Weight of Glory" (attached) for more.
October 22, 2009
With high spirits and much excitement for the future, Lyle and I polished up and released Ubercart 2.0 today. Thanks to all those who took notice, and an even bigger thanks to the dozens of contributors who made the release a reality.
Features of the release should come as no surprise, as most people have been using Ubercart 2.x for some time based on the project's usage statistics and personal experience. In the final days, we did iron out issues related to file downloads, role promotions, product kits, and Views integration. We also paved the way for smoother European use in conjunction with the UC2 VAT project.
For those that are interested, continue reading for my reflections on the state of the Ubercart development process and code, including a community effort to realign both of these things on Drupal 7 with the Drupal 7 Ubercore Initiative.
The teaser... Ubercart, D7, Small core influence -> Ubercore (or, d7uc).
Basically, I believe we have a healthy dissatisfaction with the state of our code and our development process in general. We're lagging way behind the Drupal project itself, and we weren't able to accomplish all our goals for Ubercart on Drupal 6. Furthermore, as the project grows, it's become harder to maintain and even harder to arrive at an appropriate place where the core architectural issues can be addressed.
That's not to say I'm not happy with the project. Ubercart rocks! I just think we're equipped now with the knowledge, the momentum, and the tools to make it even better. Like... way better.
To that end, Lyle and I met with several other community members in San Francisco last week to chart a forward-thinking course for Ubercart on Drupal 7. I pitched the plans at BADCamp and got some great feedback. Over the next week or so, we'll be filling up the Ubercore website, http://d7uc.org, with revised notes and ideas from the sprint. We're looking for peer review from those intrigued by the following snippets from our plans for a more solid Ubercart on Drupal 7:
- Feature specification / roadmap - Ubercore is a planning initiative launched to bring intentionality to a development process that has been spontaneous and reactionary. Ubercart has matured, and it's time to look before we leap, evaluate future features against design documents, and have better communication with our users.
- Small core influence - The initiative is aiming for a small Ubercore, i.e. slimming down to the minimum systems without which we could not have a coherent e-commerce application or build out essential features. With improvements in Installation Profiles in D7 and on d.o, we're staking the future of Ubercart as an application on having a lean, mean, and agile core with great horizontal module integration. Fields, Views, Chaos Tools, Features... oh my!
- Strict development standards - Gone are the days of uncommented functions, inconsistent APIs, and random hooks. We're planning ahead for fully commented modules and classes, full SimpleTest coverage, and consistent module structures and APIs.
- Open scrum based development process - We have sprints planned up through Drupalcon San Francisco and are inviting everyone to join in. We're working out roles and goals and have a fair bit of planning to go, but we'll start out as awkward as ever with our first sprint planning meeting on Monday. The goal is better communication with and inclusion of community contributors.
There's a lot more to relate, like where and how we'll be building this out, what our core systems and classes will be, and more. Instead of typing everything twice, I'll just work harder to get our scribblings into the docs on d7uc.org and point those interested there. We're really excited about the initiative and hope to cast an exciting vision to our users and developers, too. If you're interested in pitching in, especially if you've been contributing to Ubercart for some time, please get in touch through the contact form so I can help you get plugged in.
Two parting shots...
- Timeline. We'll have an Ubercore 1.0 for Drupal 7 by Drupalcon San Francisco, ideally by March 31, 2010.
- Ubercart on D7. We didn't settle on any immediate forward port of Ubercart 2.x to D7 but are open to ideas in this thread. Work for now will happen through Ubercore on d.o to give us a fresh issue tracker and repository set aside for Ubercore development. Whatever happens, there will be a continuous upgrade path to Drupal 7, as the idea is for Ubercart to slide into the Installation Profile space by packaging the Ubercore with other essential non-core modules.
Alright, that's all I can fit in before I lose everyone reading this mega-post. More on d7uc as we can write it down... in the meantime, you can follow d7uc on Twitter and send up three cheers for progress!