Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
By rpruitt625 on
I will be building an intermediate commerce site, about 120 products w/shipping & cc.
I will be using drupal 7 only.
I'm confused on which path to follow, ubercart seems D7 ready, I guess, and drupal commerce is an offshoot project, I guess, but have heard rumours it is not ready for prime time.
I appreciate input - I don't want to build twice - which should I use going forward?
Comments
Definitely Ubercart...
Personally I think that Ubercart is most complete and flexible, although you should read this post-> http://drupal.org/node/188814 it's a big discussion about drupal on-line store modules. Uberdrupal (a profile for d6) do magic for you but is not a port to d7 yet.
----------------------------------------------------------
G.A. Martin, Drupal Developer.
Re: Definitely Ubercart...
Gracias. Estoy tomando su consejo y correr con él!
Drupal Commerce is hardly an
Drupal Commerce is hardly an offshoot of Ubercart. It's completely new from the ground up. It takes advantage of many of Drupal 7's new features such as fields and entities, and other functionality like views and rules. As to which is ready for prime time, that's hard to say. Both projects are still in beta so your best bet, since they're free, is to build test sites using each and determine which one easier to configure and use, more expandable, and better suits your specific needs.
http://www.drupalcommerce.org/
Re: Drupal Commerce
Thanks. I should have more correctly said Ubercart was forked into Drupal Commerce.
I imagine that either one will accomplish what I need through force of will. For now, I am aiming to focus that force on only one. A fork in the road, if you will. I have a man here who says 'definitely Ubercart' - so off I go! No looking back, no regrets.
Ubercart of course !
Ubercart of course !
Set up in 5 minutes and super easy to use !
I tried Drupal Commerce ...
I tried Drupal Commerce ... used to be thought as a modern development and much more sophisticate.
Actually felt it is still a gym for developers and not fit for usual end users: very difficult to set up, and with an approach that leads you to duplicate product entries.
I spent a lot of time to get its workflow, and couldn't get it.
Ubercart takes a more simple and pragmatic approach to Drupal (7) content types creation ... and has been my final choice, so far.
Italo Mairo
www.italomairo.com
itamair@me.com
Ubercart Hands Down
I uninstalled commerce soon after I installed it, holy cow, don't want to say it's crap but it is definitely not ready for prime time, looks more complicated too. Ubercart is way better and the Drupal E-Commerce solution.
I've used Ubercart for about
I've used Ubercart for about 3 years with drupal 6.x and it's a great system, any problems I had with it was a lack of flexibility, having to combine 2 or 3 obscure modules and then implement a couple of workarounds to get what I wanted, but this was for very specific requirements, Ubercart by and large will do what most people want.
I havent moved to D7 yet for any client projects, but from what i can gather Ryan who was on the original Ubercart team is pitching Drupal Commerce (D7) as a system that you can design from the ground up to do exactly what you want, so arguably it could be a lot more difficult to get what you want if you're expecting something really simple to configure, but from a development perspective it will probably be a lot more flexible, and at the end of the day the structue and mechanics of an online store should be handled by a developer who has the expertise and knowledege to be able to handle this, if it's just an individual bringing in a modest profit in a small personal business then theres loads of services that provide a pre-built shop page, trying to use Drupal 6 and ubercart or Drupal 7 and Drupal Commerce is overkill unless you can afford to pay a web developer.
Problue Solutions
I think that Drupal 6+ ubercart can be useful for non-programmer
I think that Drupal 6+ ubercart can be useful for a non-programmer user if he only need the standard process provided by ubercart default or complementary modules. But for "crazy" or "no so crazy" customizations you will need a developer, that inevitable.
----------------------------------------------------------
G.A. Martin, Drupal Developer.
It's now November 2011, I'm
It's now November 2011, I'm wondering if people still favor D7 Ubercart over DC.
It's a really good question...
It's a really good question... I have recently ended a drupal commerce project with about of 900 lines of custom code for customization. I'm still believe that Ubercart will get you there really more quickly if you have standars needs. Commerce is great, more versatile but still too green... in my opinion, you need a hook to define a new status or state for example...
----------------------------------------------------------
G.A. Martin, Drupal Developer.
With hearing some buzz about
With hearing some buzz about Drupal Commerce, I decided to set up an install and start familiarizing myself with Commerce. Up front, the documentation is terrible, spotty, not up to date, and not conclusive. Trying to figure out how to add product types and products is more difficult than it should be. After understanding that you have to add products twice (in a half hazard way) to get your products to show, I was about ready to trash the install. Cooling myself down from this madness, I thought I would give it some more time. I found a module that automates the display of products. But that came with no documentation whatsoever, and it didn't make the process any easier. It just made it more confusing. Their reasoning for having two entries for products is not justifiable. Their are virtual no benefits to this approach. Why not just unpublish your product (and not delete it) if you still need it for other things; and use views to display your products in other ways, instead of using this two entry system? Why create this difficult product type and product display, making you work twice as much and making your DB bigger? After looking at all of this, I trashed the install and have no interest in trying it again. They either need to make it a 1 process system, or just join with ubercart. While I love multiple modules that do the same thing but in different ways, when it comes to e-commerce there should really only be one main solution that is the flagship of Drupal. I would rather see their efforts being put into ubercart. This opinion might not be correct, but it is how I feel, myself. Sticking with ubercart even though it has not quite caught up fully to D7 yet.
----
Sudo Kill Cylons
DC is non-intuitive
I have been playing around with Drupal Commerce for around a week. I am not a pro developer but have a fair bit of experience with HTML, CSS, Wordpress and Drupal. Can also do a little PHP tweaking when forced to.
At first I wasn't too scared of DC complexity. If I put my mind to it, I usually pick up the logic behind something rather quickly. Not so with DC, I found out. The odd mix of "products" and "products displays", each having "fields" and "display" areas, is non-intuitive and can add greatly to work load. I am also finding it hard to use "Views" like I am used to with content input through DC. It's doesn't integrate very elegantly with Drupal core, it seems to me.
DC also seems to be relying a lot on "rules" for even fairly simple customization of functionality, and I don't really want to get into that. DC simply scores low on usability.
Disappointment is the word. I even waited around for it to get out of beta. Never used Ubercart before but think today will be the day I give up on DC and try UC instead.
Adding product on Ubercart shop is just like creating a page
Good idea.
For standard use I can set up a brand new ubercart shop in less than 30 mns.
And adding product on Ubercart shop is just like creating a page on any Drupal website.
I abandoned Drupal Commerce
I dumped it, unfortunately after being forced to commit to it by a client. It took me 3 hours of explaining why DC is NOT the choice for the project.
Many of the issues posted here are valid, but to me what REALLY killed it was the whole taxonomy-product attributes-options deal. As of right now and according to the folks at DC, in order to have product attributes options (red, blue, green...Small, large, extra large) you have CREATE a product for each option and with an SKU. They point to other modules to accomplish the same thing, all of them in DEV stage, all of them with veyr bad documentation and that about all they do is convolute the situation even more.
In my project is a simple 59 item shop with 29 attributes per product would require a total of 1711 new SKUS. When question about this issue all you get is the standard "Check out Feeds and Bulk creation" as if that somehow was to erase the problem. My customer is tied in to Quickbooks and the idea of having to create almost 90% more products JUST to manage attributes goes againts every e-commerce standard I have ever dealt with.
To top it off, you apparently cannot bring this issue up because all you get hammered you down with replies that pretty much presume you must be a noob. They get in defense mode on the drop of a hat....but never seem to get around explaining or addressing the community's concerns.
Back when I was learning Aegir I though THAT was difficult. Man, DC makes Aegir look like child's play by comparison.
Stick to Ubercart until these cats get their act together. Betting on DC now is taking a HUGE risk that will probably put you in a situation like I am now: Behind schedule, frustrated and having to switch back to Ubercart.
Drupal vs. Ubercart
Reasons to use Drupal Commerce and now 1.1!:
About the lack of documentation:
That's not entirely true. There is a lot of documentation in the code. The documentation regarding their hooks are actually pretty rich compared to ubercart. Drupal commerce even has their api docs here:
http://api.drupalcommerce.org/
And a whole lot of great screencasts here: http://vimeo.com/channels/commerceguys
I have to dig through lots of forum threads to find information about particular old ubercart
Also, everyone in #irc at #drupal-commerce are always very helpful.
Oh and there are lots of great contrib modules coming out every week:
http://www.drupalcommerce.org/contrib
It's very exciting to be using drupal commerce. Lots of great things to learn everyday.
Commerce
I'm rather new to Drupal, but I'm committed to Commerce, after spending a month trying to figure out how to manage my stock on Ubercart.
I look at it like this. Commerce is like Photoshop. It is a fantastic tool, capable of working miracles, but only if you can take the time to get over the learning curve. Ubercart is like MS Paint. If all you need is to sketch some circles and squares, then you don't need Photoshop. Commerce can handle almost any situation, as long as you are willing to get over the learning curve. Ubercart is great is your needs are simple and straightforward.
Maybe for this crowd, I should compare Drupal vs Joomla?
-
Your comment has no merit, and is only hurting this thread. Everyone has pointed out valid pros and cons to why they like or dislike it, and all you offer is vague comparisons to other industry software. Please back your opinions up with some actual reasons or facts.
----
Sudo Kill Cylons
I have just done my first
I have just done my first Drupal Commerce install.
I don't like it.
Compared to the dozen or so Ubercart installs I've done (and other cart solutions for that matter)... DC seem counter intuitive. I think it will provide more flexibility for complicated products or workflows, however, but for ease-of-use I think Ubercart has it hands down. Having to add seperate products with different attributes is also a dealbreaker for me.
The double-handling of product vs product displays is also a little odd, but probably provides developer flexibilities.
I'm sure there are advantages to DC, but I just don't see them right now. Perhaps worth a look again later...
PetarB
Have you looked at the Commerce bulk products creation module? I understand it may not work in niche cases.
His comment his clearer than many other ones...
His comment his clearer than many other ones...
Oh one more thing. Ryan
Oh one more thing. Ryan explains the reason for commerce over ubercart.
http://www.youtube.com/watch?v=4lE4XNZx188&feature=related
Everybody has his own reasons...
Everybody has his own reasons...
That's funny, Ryan's
That's funny, Ryan's explanations really reinforce why Ubercart is and will probably be more attractive to people wanting a Drupal commerce solution.
I'm not saying it's better, I'm just saying Ryan's presentation, saying Ubercart is an out-of-the-box solution, as opposed to DC which he clearly positions as a building toolkit or 'framework' for a commerce system.
I would much prefer an out-of-the-box solution which can be tweaked to requirements, than a framework where I have to learn new ideologies, neologisms and workflow philosophies, and I'm probably not alone there.
Perhaps I didn't read the documentation well enough stating that DC is a framework, rather than a solution.
It will be interesting to see what happens to DC, and Ubercart.
One thing is clear: Ubercart really needs to close or review its ubercart.org forums, they don't seem to be supported much anymore, whereas most of the support and feedback is happening right here on Drupal.org.
Ryan + explains the reason =
Ryan + explains the reason = Epic Failure for the masses
Contrary to popular geek philosophy, complexity is not attractive it's bloaty boring.
My 2¢
If I'm going to build a system that is going to handle sensitive financial data, do I want a box of parts or do I want an out-of-the box system that has been used in thousands of cases previously?
Honestly I have never heard anyone complain about ubercart's performance. Also, I have two Drupal 6 e-commerce sites i support that were developed by someone else. It's already hard to figure out what, how and why something was configured a certain way. I can't imagine the challenges I'd face if I had to decode how the store was built from the ground up.
By the way, I have major respect for Ryan and what he has created with UC and commerce. It's truly amazing enterprise-level software -- only better. I have to admit I was excited about Commerce initially. But I have chosen to stick with Ubercart for the reasons above.
A list of some of the Drupal sites I have designed and/or developed can be viewed at motioncity.com
hah, feel free not to listen
@espirates - hah, feel free not to listen to it. : P
However, I'm not turned on by complexity or anything. In fact, my sincere hope is that simplicity will be achieved through use case specific distributions that can then be customized a la templates in Word. You can't get there by just hardcoding straight toward simple, though. Imagine if all we had was SimpleViews with no Views - all of our sites would necessarily be limited in functionality, but you're not going to drop a newbie into Views with no training.
This vision - for the foundation to be packaged up into user oriented Features / distributions - has been my communication all along, and we're starting to see it come to fruition now through projects like MartPlug and OpenDealsApp. A single framework that can power those two widely different stacks will necessarily be complex, but I have no delusions about "Joe Newbie" being able to build those on his own with a blank Commerce install. ; )
Ryan,It looks as though
Ryan,
It looks as though peoples fears about Drupal Commerce, about having to create extra products, to add variables to products like, T-shirt colour, sizes and optional extras. Are about to become a thing of the past : )
With your brand new module:
http://drupal.org/project/commerce_custom_product
Drupal Commerce is Drupal to the core.
When you learn Drupal Commerce, you end up increasing your Drupal Development skills overall, even for non commerce related tasks.
As for me, I love to learn useful Drupal development skills!
@jlhs
You're missing the point, most users/site owners could care less about increasing their drupal development skills, they are not developers or programers, many are business owners or bloggers who simply want to manage their content. To assume everyone should have developer skills to run a web site or online store is asinine.
There are two points. Some
There are two points. Some people are looking for that, others aren't. The ones that are won't mind digging into Commerce now, and we'll do everything we can to help them. The ones that don't actually are addressed by our roadmap for Commerce 2.x, which has always been the intended place for us to hone in on the non-developer store administrator. See the "Planning" section of this UX roadmap thread from January. I don't think any of us assume everyone should have developer skills to run an online store.
A great crystallization of this plan came out of a Commerce Guys retreat last week. In his "Ignite" presentation, rfay proposed the goal of absolutely hiding the Rules UI from users unless they absolutely want to see it. Now, we obviously had to launch 1.0 with the Rules UI exposed; we just never would have launched if we waited for all the custom UIs to fall into place. But now that we have the foundation, it's full steam ahead to hide the complexity through 2.x work and the distributions that are already being released. : )
espirates said:"To assume
espirates said:
"To assume everyone should have developer skills to run a web site or online store is asinine"
Can you please point to where, in my previous message I assume, that everyone, should have developer skills to run a website or online store?
My message was, if you scrape just below the surface: "I" as a "developer", "enjoy learning, new Drupal development skills". Also when I said, "when you learn Drupal Commerce", I am referring to a developer learning Drupal Commerce, considering this whole thread has been filled up with, developers talking about setting up stores, or at least people who have access to developers. Which I assume you are one yourself.
As for your run of the mill website owner, it is of course their prerogative to learn the development side of Drupal and commerce or else to want to have nothing at all, to do with development side of things whatsoever or even something inbetween. None of these being bad, people need to allocate their time, where it is best suited to progress. Someone who runs a website, would have to at this stage, however get someone to make new product views manually at this point in time, if they added new sections to their store. I can see this being a bit of a hiccup.
Out of the box setups coming, for the time conscious developer, that wants something closer to plug and play. The Commerce Guys team and the rest of the community is working on pre-packaged out of the box solutions for the future (Some are starting to come out even now).
Drupal Commerce vs Ubercart? ... Drupal Commerce !
Yes ... probably is right. DC is more complicate/sophisticate than Ubercart in its implementation, as this last one looks like a more out of the box solution.
But it seems just as an appearance, at the beginning.
At the beginning I was really surprised and disoriented by DC (apparent) complexity: Product types + Product displays. Twice inputing similar contents ...
So building this library catalogue: www.inuedizioni.com, I was (I had been) confident to stick with Ubercart.
I tested both for months, and Ubercart seemed the be the easier and right solution, also for and from the site manager point of view.
But going thorough and facing the concrete workflow of building the working solution, I completely changed my mind. Then was the "light" of Drupal Commerce.
For any content of my site (pubblication, article, ecc.) I had to forsee it should be sold as a physical or digital product ...
With Ubercart the node is the product (!), and that is sold. If it should be sold as physical or digital version, this is handled defining variants in the checkout process. Actually the product is the same, but sold as in different version. Strange ... also because this way leads you to great matters. I felt I was managing quite the same, things/product that actually are not the same.
So I began thinking that, still staying on Ubercart, I would better need to define a simple node that would reference, as a display (!), to other nodes that would be the real products: the physical and the digital one, with different prices and characteristics, and autonomous check out processes.
So I found myself just, and exactly, thinking the same way Drupal Commerce works ! And that was the exact time I began loving Drupal Commerce, just because I understood its approach and language, that matched perfectly my solution ...
Drupal Commerce leads you to greater freedom in structuring and managing the products you want to sell.
It is a more sophisticate and power solution in selling contents from your Drupal site, with the great advantage that it let's you keep separate at the right level the power of Drupal in creating and managing free contents (nodes, and possible product displays) from the products creation and management in your shop. Drupal nodes just remain nodes (and not products), so Drupal still remains a CMS, keeping at a deeper level the Product Manager System. You eventually can attach products to one of more of the nodes themselves, just selling the products and not the nodes.
At the beginning It seems to be, and probably is, more difficult and time taking to set up, if compared to Ubercart. But this is due to the possibility you have, and it brings to you, to personalize it exactly to the specific needs you have. With Ubercart is the opposite: you should bring and probably downgrade your specific needs to what Ubercart behave, and just lets you to do. With Drupal Commerce once the initial set up is done, with product types and displays schema definition, so as with all views you need or you might (and will) need ... well, then it becomes a much easier and perfect process/mechanism to handle, also for the site managers (back end) point of you.
That's why, so far, I have learned to handle and to really appreciate Drupal Commerce for my actual needs, and now feel Ubercart has become my past. My site managers will have no problem to handle product displays and contents creations, once that everything has been properly set up, by the developer (that should keep its role in building the perfect solution for them, and should be able to do it ... with his skills and any fear).
www.inuedizioni.com has been presented as a best practice in the last Drupal Day 2011 held in Roma last 4th of December 2011, also for its Drupal Commerce solution implemented (http://roma2011.drupalday.it/sessions/il-nuovo-catalogo-informatizzato-e...)
I here attach a link to a slide from my presentation/talk about it: http://www.italomairo.com/downloads/drupalcommerce_vs_ubercart.zip
In this I tried to better explain Ubercart vs Drupal Commerce in their approaches, for what I realized in my experience, and the reasons I finally and happily choosed Drupal Commerce ...
I really feel and hope I am not been wrong, so far. ;-)
Italo Mairo
www.italomairo.com
itamair@me.com
Oh, wow! Thanks for sharing
Oh, wow! Thanks for sharing your experience and your presentation. I wish I lived in Europe so I could travel to all the Drupal days and hear how people are implementing Commerce. : )
Thank you to you. I really
Thank you to you. I really felt I had to do this, to you, also as a further feedback after my doubts expressed initially to your Drupal Commerce, in the DC Forum ... Now these are gone away, and I am just looking forward to better and better improving practical solutions with DC.
Just let me know if I was wrong somehow in the analysis and slide schema content ... ;-)
Italo Mairo
www.italomairo.com
itamair@me.com
With Ubercart is the
That's not correct. So far we have set up dated Event sales, free downloadable sales, paid downloadable sales, and shipped products, and in each case we found a combination of existing modules for Ubercart worked just fine - for very difference ecommerce 'models' and product types.
Here is a nice review that
Here is a nice review that might help to better understand the state of this art: http://www.markroyko.com/blog/2011/12/14/ubercart-3-vs-drupal-commerce
Italo Mairo
www.italomairo.com
itamair@me.com
Very fair, balanced
Very fair, balanced review.
There's one thing however, that I take issue with. The point is made that for products with different attributes, DC puts you in the situtation where each different attribute requires you to create a new product entry. This is then presented as an advantage for DC, for retailers with SKU issues, where each a products differentiated by attributes needs better SKU identity.
It ignores one simple fact, however; there is NOTHING to stop you from doing this in Ubercart if you wish! But - and here's the kicker - the reverse is not true for DC.
To us, and our customers, this is a pretty fundamental issue.
Some other great points are made, however. And this issue with documentation for both platforms is an important one. Thanks for the link!
Hey PetarB, good feedback,
Hey PetarB, good feedback, but perhaps what can clarify the issue with respect to Drupal Commerce is that you can create "customizable products" where the customer say has to select an option from a list associated with that product in the cart - but the same base product is always referenced. We had to differentiate these somehow, and it's a very thin distinction, but attribute fields on product types are those that specifically result in the selection of a new product while product line item fields exposed to the Add to Cart form can be of any type and use any field widget; they don't require a unique underlying product for each option, and the data will be stored alongside the product reference in the line item.
I just specced this out for someone recently, where they needed to get a shirt size for a conference attendee along with the registration without actually charging for the shirt or showing it as a separate line in the cart. The solution will be to add a shirt size select list field to the product line item type and expose it to the Add to Cart form. This same process can be used for product customizers, too, like those sites that allow you to upload logos and write text to customize t-shirts, mugs, etc.
There's always a caveat of course. You must use a unique product line item type for each configuration you want; it's not based on the product itself but the line item used to represent the product in the cart. Conceptually, I see this as using the line item to bundle together the product along with whatever additional data you need to go with that product for the particular customer. I can't remember if we have videos of this functionality on http://vimeo.com/channels/commerceguys, but I think we do at least in Randy's video on quick-and-dirty coupon codes. Hardly an ideal example for what I've described above, but it demonstrates the functionality.
The recent development that that video wouldn't show is my Customizable Products module, which allows the creation of any number of product line item types through the user interface. The only improvement planned for it at the moment is to be able to associate a product type with a product line item type so you don't have to configure separate product displays for your different customizable products. Beyond that, I'd love to hear your ideas on how to simplify this working on top of the same underlying architecture.
So true !!!
So true !!!
Understanding Entities through DC
I had exactly the same experience, used to use Ubercart but was never really all about building commerce sites but I had seen, read, and listened to enough about Commerce to know that if I ever had to fulfill an ecommerce request that the new tone was Commerce > Ubercart.
Fateful day arrived where a friend had a crisis and in one weekend it was like one big Drupal Commerce cramming session, like the kind you used to have in college.
For us, my designer friend only touched Drupal like 4 years ago so he was learning the whole time but when we the product type -> product (one for each VARIATION!) -> product display content type -> product node finally clicked that was it. Like it was just using Drupal again and everything made sense again.
It was really nice because after that crash course my friend really got the hang of content types, fields, and different content nodes because he was able to stick with me the whole way through the Commerce work.
Also I found Commerce to be an exceptional demonstration in understanding Entities. Like users, taxonomies, etc made sense as to why there were entities, but I never really appreciated the understanding, thought behind it until, and practical use for entities until I had to follow the 4 step process that Commerce forces you to follow.
It's like after you get done with a little ecomm site with Commerce, you just end up understanding how Entities work as well.
Such an awesome deal :D
A few months later, a couple of due corrections
I posted a reply a few months ago about some of my personal frustrations on using DC and I think a few months down the line my comments deserve a correction.
First of all, after having worked with DC for almost 6 months in this massive project I am on I have come to realize the possibilities of DC dwarf Ubercart, albeit not without paying a fairy high price for the learning curve. But, When has that not been the case with Drupal-anything? Many of Ryan's claims are finally coming into the light and I can finally see what he was talking about and the gigantic difference in "potential" of DC vs. Ubercart.
But, let this be a warning for the noober/intermediate developers, one that I am sure developers far less reckless and far more lucky than me will probably do not need to be reminded off:
A) Gauge your clients well. I made the very unfortunate mistake of not properly researching DC and basing my choice on brief reads and generalized hype. To add to the mess, I signed up a client who was, by all accounts, the least technical-anything person that a developer could ever find who in turn put another person just as noob as she was in charge of managing the project. A combination for disaster. The fact is, if your client is a complete noob who signs away a contract without even understading the importance of the specification sheet, DC will get you in the way that it has gotten me: In a lots of trouble. Huge trouble. Massive trouble. 4 hours-of-sleep-a-day for three months trouble.
B) Team up. We have to. I am not sure how many commenters here are independent single developers like me, but the days of "lone wolfing" are coming to an end very fast. There is just no way to keep up with everything, specially since the mobile/tablet factor came into place. TEAM UP. This will be the LAST drupal project I ever do alone. From here on out, I get a big project, I am off to find partners to split the goods with. Better to make half the profit and sleep a normal schedule than end up fighting month after month alone against everything.
C) Good development procedures. Aegir + Drush + Git makes a huge difference. And I am sure that really is no surprise to the veterans, but I think there is still lots of people out there who are not using the proper workflow.
D) Expect the unexpected. While this is a common thing with any Open Source project, in Drupal 7 + DC the "unexpected" can be worst than you have ever seen. A simple error on an entity-related module can throw the entire thing into massive disarray witout you even trying. UPDATE WHISELY. Don't just pm-update blindly because that will eventually will get you. In this environment, when the gremlins come out, they carry bazookas and RPG's that will demolish even the most optimistic of developers.
E) Be nice. And that comes from my personal behaviour quite a few times. Frustration needs to be aimed at everyone else but "the bosses" (my nickname for the top Drupal hierachy of Drupal developers...you know, the ones who actually make the stuff we use.) You have to. Not just because it is the right thing to do, but because if not, being such a small community as it "really" is, you will be tagged as troublemaker and your queries about issues will be justifiably ignored. Note to self.
And whatever you do....DON'T EVER, under ANY circumstance allow your client to sign up with ANY Intuit product. And if they do, tell them you do NOT do integration with QUickbooks. That company is one energy-sucking, wall-punching, curse-generating mess that is stuck in 1995 and will make you want to tear your hair, your neighbor's hair, his dog, his dog's vet, the postman's hair out.
My 2 dollars of change.
Great!
Some excellent tips there kannary100! Thankyou for sharing these well thought out points : ) Everything was useful.
That Quickbooks integration sounds like a vampire...
I guess for lone wolfs, is not to get desperate for work or else should I say intrigued by projects to take them on, to find you have taken on a time draining Job not worth the money.
lol @ many of the comments,
lol @ many of the comments, especially integrating with Quickbooks. ; )
Thanks so much for coming back to post the update, and I sincerely hope the project comes through for you. And then I hope you get a week of R&R on a beach somewhere!
On a side note: feel free to contact me if you think of ways we can better prepare people evaluating Drupal Commerce so there's more meat and less hype. "Entities are amazing and Rules will change your life!" is probably more than enough to get anyone into trouble. The more clearly we can set expectations, the better.
Another small piece of advice
Check out the Drupal Commerce video on Lynda.com. It's well worth the time spent watching because it will make Commerce much easier to understand the first time around.
I have a site I'm SLOWLY working on and the video helps tremendously.
Mike
What about containers?
I read the whole thead with interest and curiositsy.
I think that the DC way to separate the product from the
product view, sounds great. But I will not be able to explain
this to a shop maintainer.
I regard myself not as a programmer and I am new to
Drupal and DC and now checking options for several
heavy wight projects to come. So forgive me if I do not
always use common Drupal terminology (yet).
My following assumptions:
-The new structure to divide a product entry into a
product and it's view part is given.
-That the normal guy who actually fills the shop with
products gets confused easily and makes mistakes, or
is unwilling to put data in, is what I expect to happen.
-There are not only problems with the creation of
products for normal guys, but also with deletion.
What I remember to have seen in offline shops a concept
that could be useful here (container boxes):
The idea:
You leave both possibilities intact, display and products,
but you make both entry paths powerful enough to be able to
"see" the whole picture of a product from there.
If this can be done with the Drupal tools already,
I am curious to know.
(If I was a shop maintainer I would choose way No.1
of the following 2 ways.)
Here is a first draft...
1. A shop seller uses the "products" way:
The mask for him could be like this (if you introduce a container
element as a window to a mask of a related table):
If the produce is a one-one-Relation, the shop guy
can see all product info from the mask and can edit
also the data of the related table
If the produce is a many-one-Relation, the shop guy
can see link to the group info that is common for
all products in the group and, if the group info
already exists, see that end edit that.
If the last product of a group gets deleted, the
group data also gets deleted, otherwise not.
2. A shop seller preferes to go the "Display" way:
The mask for him could be like this (if you introduce a
container where you can see the related product details):
(Or this could be a table instead of a list, like Filemaker does it.)
The first product is added automatically for a
new Product Group and it is not possible to save
the Group if no product is in the box.
And a delete will delete all the products.
The + is for changing the order inside the
outer box.
([EDIT] opens up some layer on top to makes product
detail Fields editable?? -not sure...)
Coming back to the original subject of this thread:
My setup plan might be something that can be built with views and relations,
I will need to dig into that further.
If so, this would mean to me that the most central argument, saying that
DC is to complicated for an average non-programmer shop maintainer
(opposite to other solutions like Übercard) would have no impact any more, correct?
Thanks for reading this.
drupal commerce or ubercart?
Neither of them if you are dealing with real money.
If your plans were to train yourself with drupal/php/eshop I would start with UC.
As for me, I spent a lot of time with both of them, and ended up with a custom set of modules. Although I should confess - partially, I had to use their code to build up my own.
Anyway, IMHO a good reliable business software will never be free or open-source. Either paid, or your own built.
Last I checked, the majority
Last I checked, the majority of websites out there are using free or open source shopping carts. Building your own is becoming obsolete these days with all the plug and play software.
Probably. But they are not
Probably. But they are not making money.
Absolutely wrong. Plenty of
Absolutely wrong.
Plenty of our clients are making money using Ubercart, and some other open source solutions.
DC or UC ...and the winner still is ...UC in 2013
I need to work quickly, I need good documentation and a module that is user friendly and intuitive, I found DC very very! frustrating. UC is out of the box ready (mostly) and most of the time, stores need the basic functions without you having to think about adding special rules etc.
If you need to get a programmer to do fundamental every day actions then you are killing off the modular approach to Drupal. You may as well hire a programmer to do the whole store for you. It might take you the same amount of time to figure out how to work DC, LOL. You don't normally have to hire a programmer for most Drupal sites, but with DC you sure will....not for me thanks, but good luck with it!
Unfortunately think it boils down to money, DC has its "partner" and is looking to sell the support package... I prefer the sponsor or donate route ...keeps transparency...
I guess it was to happen sooner or later...I only hope the community stays in support of UC to keep the balance right.
For now I am uninstalling my DC on my latest project for UC, and slightly annoyed about the amount of unnecessary time it has taken to do the most simple things.
Just for clarity - did you
Just for clarity - did you start from Commerce Kickstart (1.x or 2.x?) or attempt to build everything from scratch? The best comparison of UC to DC would be UC to Commerce Kickstart 1.x.
For clarity
I did everything from scratch, but that was as a result of upgrading from D6 to D7 and adding a cart afterwards. I have used the Kickstart for other projects, It was not ready for the enduser, so moved over to UC as a result.
Is there a problem with building from scratch..? If Commerce only works as a distribution then we may have problems. I believe the power of Drupal is with modules not distributions. Distributions are a convenient way of starting quickly. But websites tend to evolve into shops...forums....blogs, news etc. It is often easier to start with basics and add modules and dependancies as required. One size does not fit all IMHO.
For DC to work in my opinion - it needs to list all the modules needed for it to work successfully like the average store created on other Open Source Carts. The sort of features you would expect to see and just work and easy to use ...shipping, payment..attributes, These are not listed on DC main page as recommendations. I think knowledge base needs to be maintained within the Drupal website first and foremost.
But with that said, I am as aways grateful for all the contributions to the Drupal community.
Nope, it's not meant to only
Nope, it's not meant to only be used as part of a distribution, I was just focusing on Kickstart 1.x as the nearest comparison to what we included in Ubercart (although even in Ubercart I put in a variety of payment method modules and Lyle put in shipping modules that you won't find in Kickstart 1.x). Our focus on distributions is primarily about "default stores" or templates that less Drupal-savvy users can take and launch quickly. I agree with you that one size won't fit all, so we do need to ensure the core module set itself is easier to work with.
We can definitely improve the main project page, though - I'll look into that. We only link out to a handful of contribs (i.e. Shipping, PayPal) and could maybe provide links to a more comprehensive list. We've been working on a better contrib module listing to replace the wiki format we had on DC.org - the hardest part is really just curation and staying on top of all the modules being written. : )
Thanks for your thoughts!
I found this thread being a
I found this thread being a n00b and running a UC store which i build myself with the help of this community.
We decided to build a new store and now i'm looking at DC, after fiddling around with kickstart2 i think it's way to complicated for people like me.
Shipping outside the USA and the UPS Module are the first things i've tried to accomplish but i already got stuck with that while it was a piece of cake with UC.
Just trying to give a heads up and maybe find someone who likes to take the advantage to help me
Same problem here...
Same problem here and I do not want to face all the problems that I had when I started working on Drupal, so there is no way that I will use Commerce until they understand that we are not all developers or that we have something else to do but trying to understand this system.
Do you think that the Ubercart community will survive ? I hope so !
Recommendation for non programmers
I think the right way to approach drupal commerce is to install the kickstart 2 distro and use it..
A) To build upon it.
B) As a configuration documentation. You can take a look and try to mimic configurations for your particular store.
Drupal Commerce is a framework and the biggest documentation about how to configure it, is right now the official distro. Ubercart is the past... it will survive for a while.. but if you hold on to it for too long... would be like using drupal 6 for new sites, there is not future there..
----------------------------------------------------------
G.A. Martin, Drupal Developer.
Can you imagine...
Can you imagine that we don't need new useless features and that we just want to keep selling on our shops ?
And if new features were needed I would just pay a developer to do them !
Ubercart might be the past for you but I am far to be sure that Commerce is the future... Just having to find a "right way to approach" means that people who did Commerce are totally wrong.
Thank you anyway.
Making trolling comments in
@make-online-shop
Making trolling comments in the forums just reflects poorly on you.
You've provided no actual arguments, so it's not like you're convincing anyone.
I haven't used Ubercart, but
I haven't used Ubercart, but am using Commerce. Being a complete novice in Drupal, I found it initially quite confusing - so I bought a kindle book and read up and experimented. I eventually realised that the product display could be linked to any entity I wanted (for me a calendar event) and that I can associate a ticket product type and associated taxonomy with the event, as well as run Commerce Registration and Entity Registration alongside - this becomes a very impressive and flexible framework, which means that you can really embed the online shop into the wider capabilities of your website. Personally, I think that Commerce Guys have done a great job - but also recognise that it isn't going to suit everyone. Next project is to try and link it with MERCI.