Closed (fixed)
Project:
Commerce Core
Version:
7.x-1.x-dev
Component:
Contributed modules
Priority:
Normal
Category:
Support request
Assigned:
Unassigned
Reporter:
Created:
7 Mar 2011 at 15:42 UTC
Updated:
28 Oct 2016 at 13:51 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #2
rszrama commentedThis one apparently never even made it onto my radar, but the simple answer is you'll have better data available in DC to work with than you will in UC. You could potentially replace modules like UC Who Bought What w/ Views, though I haven't tried that particular challenge yet. ; )
I'd give it a go if you haven't already dove in on this project.
Comment #4
OsterD commentedHi Ryan.
Any news about a possible Groupon Clone?
I was thinking, is it possible to have on Coupon module a start / end date of validity of the coupon for a specific product?
e.g. imitating the behaviour of a groupon-like site / eshop where it has :
- a product on sale with certain percentage % off
- valid through start / end date
- valid when minimum purchases are reached
- non valid after maximum purchases are reached
Possibly rules can be extended for the above and via views display this new information.
But my next questions are...
- How would we go about having each product "mapped" to a specific vendor where on its record(database data) has a charge percentage - a simple 0 - 100% which shows which is the percent we charge the vendor of a specific product in order for using the system AND
- when a coupon - product is purchased we(the eshop groupon-like) commission the above percent on customer's payment
Any insights?
Comment #5
OsterD commentedJust changing status that I forgot to change!!! and reposting,
Hi Ryan.
Any news about a possible Groupon Clone?
I was thinking, is it possible to have on Coupon module a start / end date of validity of the coupon for a specific product?
e.g. imitating the behaviour of a groupon-like site / eshop where it has :
- a product on sale with certain percentage % off
- valid through start / end date
- valid when minimum purchases are reached
- non valid after maximum purchases are reached
Possibly rules can be extended for the above and via views display this new information.
But my next questions are...
- How would we go about having each product "mapped" to a specific vendor where on its record(database data) has a charge percentage - a simple 0 - 100% which shows which is the percent we charge the vendor of a specific product in order for using the system AND
- when a coupon - product is purchased we(the eshop groupon-like) commission the above percent on customer's payment
Any insights?
Comment #6
ranx commentedsubscribing
Comment #7
rszrama commentedSorry, no news or insights from me, but you might take up the topic in the Commerce Coupon project's queue. This isn't really a topic of concern for the core Commerce project itself.
Comment #9
yannisc commentedWe are in the process of developing a groupon clone based on Drupal 7 and Drupal Commerce. We intend to give this away for free as a Drupal distribution.
You can check it at www.opendealsapp.com. There is a demo at www.opendealsapp.com/demo.
We think we'll have the distribution files ready in the next week.
Comment #10
rszrama commentedWow, wonderful news. Can I publicize this?
Comment #11
yannisc commentedYes, you can, but please mention that is currently in alpha1 stage and that the distribution files will be available in at least one week from now.
Comment #12
rszrama commentedWill do! I love seeing these distributions come up. : )
I saw you have another distribution in the works called Open Commerce. I don't suppose there's a different way to brand it like you did for the Deals distribution so it's differentiated from the Drupal Commerce project itself (and other potential distributions) by a more unique name? For example, recidive used "MartPlug" as the name for his Drupal Commerce distribution targeting a very similar feature set: http://drupal.org/project/martplug
And would you mind if I put someone from Commerce Guys in touch about cross-marketing your distributions? : )
Comment #13
yannisc commentedRyan, you have a point. I agree, we should come up with a more unique name. We'll work on this.
Regarding open deals, of course we would like to work together promoting it. Any help is more than welcome!
Comment #14
rszrama commentedExcellent. I'll mention it to Kevin here at Commerce Guys, and I'll be following along on Twitter. No hurries on the Open Commerce name, I'm sure you have plenty to do to get Open Deals up and running! I really hope it does well - it's a great example of why I think Drupal Commerce is going to succeed as an e-commerce framework. : )
If you have any feedback on how to improve the core to make it easier for people to build custom distributions and applications, be sure to post it in the queue. I love getting issues like that. ^_^
Comment #15
yannisc commentedRyan, you are right, we have plenty of work to do on Open Deals. Our main concern at this time is the way to pack it and distribute it in a Drupal, nice way that will make it updatable.
The classic profile method with features seems to me too complicated and hard to manage. On the other hand the approach described here: http://www.lullabot.com/articles/5-step-drupal-distributions (with sql dump) seems easier but system is not updateable.
We are working on a hybrid solution where the sql dump will include a module and a theme updatable from the repository, so when needed we could update these two only.
What do you think on that?
Comment #16
decibel.places commented@yannisc
I would stick with the "classic profile method with Features" - it's the Drupal-ly way!
The Strongarm module extends the settings exportable in Features: http://drupal.org/project/strongarm
While looking for ways to extend Features I came across the Features Conf Wizard module http://drupal.org/project/featuresconfwizard which adds a checklist with configurations not exportable in Features
Although there are some limitations:
Since CCK custom content types do not export well in Features, I usually use the Content Copy module for export and import.
I generally also include a doc with configuration directions for a Feature.
Another way to include SQL is via the Backup & Migrate module which allows for export/import of selected tables: http://drupal.org/project/backup_migrate
Best wishes and keep us posted on developments! My original requirement for a Groupon clone never progressed beyond the talking stage, but the work you are doing is great!
Comment #17
rszrama commentedHmm, you know, I've never really had to think about it, but I'd probably look for ways to avoid a SQL dump. If Features / Strongarm get you that, I think it's worth researching. You might check with recidive (he's in IRC all the time) - his MartPlug distribution depends heavily on Features. He might have some advice for you regarding how well it's working and things to look out for.
Also, I'm gonna move this to "fixed" so people can see it in the issue queue. I'm so stoked about Open Deals. : D
Comment #18
yannisc commentedThank you Ryan and decibel.places for your suggestions.
We have been investigating all day with my team on the proposed solutions.
Finally, I think we'll go with the back_migrate module for export/import and have a module and a theme installed so we'll be able to update everything to fix bugs.
The advantages are that it is very easy for us to update the distribution and also it will be very easy for people to install it. They'll have to install it like Drupal and they are ready!
Comment #19
yannisc commentedWe are ready! You can download the Open Deals distribution from here: http://drupal.org/project/opendeals
Remember, this is the first (alpha1) release.
Comment #21
stylozashik commentedHey guyz,
This idea is awesome and thanks to yannisc,
But am very new to drupal and wanted to know in depth to setup and publish this site on my host,passionately.
Can anyone help me by providing hyperlink <?>
I will be wait for someone help,I allready finished the design part and wanted to know more in details.