Ubercart

I'd really like to see a flexible report building system, whether it relies on views or a separate stand alone reporting module. It would be great to be able to build a custom report based on any available data set.

Ideally, a drag and drop interface that lets you build as simple or complex a report as needed which could then be themed through a .tpl.php file and/or css, and would be assigned a menu path and have permission settings.

This would let you build reports to list customers who have purchased a given item, or all items purchased by a given customer -- within a date range, or over the lifetime of the site, etc.

Exportation of reports to various formats would also fit nicely into this, but I this is the one area I think is a bit lacking and would help promote wider acceptance of the ubercart system.

Might also be worth looking at a mass import/export utility to import or export product catalog's en-masse.. I see requests for that functionality come up rather often. Though that too may be best suited as a contrib.

Let me start by saying +1 to everything on the ryan/lyle list. Also, I think the most important thing we could work on during this release is community involvement. We should work on streamlining the issue -> patch -> review -> commit process, and work on getting as many people as possible involved. Ubercart's primary advantage over other shopping systems is the community, we should do everything we can to grow the community, and encourage it's involvement in UC3.

That being said, here are items I'm interested in working on for UC3.

General usability improvements. We have noticed a lot of stumbling points while working with clients, and during training. I think we need to make a lot of workflow / usability improvements. Although Tapir and conditional actions are a great start, we need to take a broad look at the things people do, and work on making them easier. A good example is adding attributes to products.

I would also like to work on the attributes system in general. To start with, every attribute should have an individual sku. I would like to see us drop the serialized array method we are currently using, however I'm still working on how we would go about that.

Theming could really use some love.

We should focus on product types. For example, currently it's assumed that products are shippable, unless you explicitly say they are not. Even if a product is not shippable, it has shipping fields attached(items per box, dimensions, default package type). In my opinion the default product type should have a price and sku. From there you could add shipping fields, download fields, attributes, etc.

I think we should stop using the term SKU. From my experience that term is not used outside of North America.

Finally I think we should work on improving the current api, and add xml-rpc methods for a number of common items.

There are other items on my list, but I think that's enough for now.

Good ideas coming. I did totally forget reports on the lists! Also, I noticed someone just posted in this old thread on theming improvements and figured it would be good to link it in. More food for thought.

Linking in another thread with some useful input. This one touches on issues related to multilingual sites that abstracting products from nodes through the planned CCK dependency might help out.

I realized after reading Dries' blog post on Google and the semantic web that I totally left out one of my "Big Ideas" (TM) for the future... a semantic shopping cart. We need to expose product data at the very least using the RDFa protocol currently being implemented through Drupal core. This means our job is being made even easier as I type, and it will take that much less work for Ubercart to be compliant. How cool would it be to have the first fully "semanticized" shopping cart system? Drools...

It may seem trivial/nit-picky, but I would like to see form_set_error() work as expected for forms in Ubercart checkout panes. Currently form fields with errors do not get highlighted if they are in a checkout pane loaded via JQuery. From an end user perspective, having consistent looking forms is a pretty fundamental thing. It looks pretty unprofessional when form fields on the same page behave differently.

+1 to revisiting the attributes/options. Great feature, but currently very difficult to use or explain.

I would really like to see multiseller capability in the next version, or at least some adjustments to core that would make it easier to add as a contrib module or roll in with Ubercart Marketplace. Doing this currently requires overriding (duplicating) a lot of code to make relatively small changes like adding a foreach loop or adding a seller id.

I would also like to see a few more hooks and callbacks to make customization easier. For instance, in uc_paypal_ipn, there's a switch statement that logs Paypal's transaction status and does a few things on some statuses (such as completing an order on 'Completed'), but there's no way to hook in and, for instance, fire off a notification if the status is 'Failed' or 'Denied'.

And I'd like to see theme_uc_catalog_browse() reworked. There's too much going on in that function, and although it can be replaced with a Views view, it would be better if it didn't need to be overridden.

I would like to see the ability to give each attribute a discount. Say when I'm using attributes to sell different product sizes like selling liquid products with different bottle sizes. Instead of having to create a different product for each size I use attributes for the main product and each bottle/box size is and attribute with a different price but currently it seems that discounts can only be applied to the main product and not the attribute. This would save on having to create a lot of redundant product pages.

Also the ability to have multiple pricing would kick ass reatail/wholesale or per role. I think most of the carts have this implemented already or at least in module form.

I'd really like to see some cross-sell / up-sell functionality. To start, it could be something simple, such as an administrative form that allows relationships to be defined between products. Then when a particular product is displayed to a user, cross-sell products would be shown in their own summary block. This same functionality could also be used to showcase the more "advanced" version of a product (up-sell).

I'd also like to see this same type of functionality on the checkout page. From what I've seen, pizza places do a good job of this on their websites. When you're in checkout reviewing your order and entering payment info, they present an option to immediately add chicken wings or soda to your order. Don't have to leave the page, just click the button and it is added.

In the future, you could write algorithms so the functionality has intelligence, where users are presented with cross-sell and up-sell opportunities based on the purchase habits of others (rather than having to hard-code relationships). Amazon has done an amazing job of this, having collected data over the years and leveraging it to present users with other products they would be most interested in buying.

Hi Ubermates,

Long time I didn't post here, but I continue to closely follow the Ubercart Project

I like the battleplan. More Ubercart will be close to Drupal core, better will be the product.

Today, there are a lot of things that ubercart could get rid and would use a little more drupal Core API to do the same things, but with a better flexibility and usability.

Here is the battleplan I would write if I were a core member of the Ubercart Project :

• Product more inline with core
  As you said, dependency of "fields" of D7. But I would remove product class UI (it just create some new content type, so add a checkbox in the content type add/edit form to make it product instead of creating a content type UI. It will be better to maintain, and drupal users will not be lost).
• VAT Support in core
  There are 2 things that broke my head with ubercart. The main one is the tax management. A big part of the world use different tax system that ubercart planned at the begining. This is, IMHO, a too important issue to let it managed in a contribution.
• Better attributes management
  The second thing that make me blaspheme is the attribute system. On the begining it was not a part of the node object, needed a custom and not very flexible API... Now it's a part of the node object thanks to zmove's patch x_x. I think the next step is to integrate them with "fields" the next "CCK". To be able to define any CCK field as a product attribute.
• Order as node
  The order system of ubercart is pretty good, I remember the line items nightmare of the begining of the project, it was tricky . I think the next step it to make orders more inline with drupal and transform them as node (with "fields" to manage shipping and billing address...) all fields of an order could be easily added or removed using "fields" possibilities. Ubercart would juste create a default order node with some default fields, and drupal would do the rest.
• Stop CA, love Rules
  Rules is awesome, fago is awesome, Ubercart is awsome, Ubercart team is awesome. Why all these awesome people don't work together ?. I think Ubercart would be definitely more user friendly and inline with drupal by using the excellent Rules modules instead of providing conditionnal action. This is a long discussion, I know Ubercart team position to try to not have some dependencies, but I'm still a rules and a non-module duplication supporter
• Stop Catalog, love Views ?
  Another thing I would like to see improved the views integration. I already know the Ubercart position too to have an out of the box catalog for non drupal users, but with some good default views and a better view integration all the UI will be better, more centralized and easier to tweak.

I would add that, for me, in a perfect world :

• Product would be nodes, all product stuff would be provided by "fields" (attributes too) and all product display would be generated with views (even the admin ones)
• Same things for order, (imagine you can create your custom order admin just by tweaking some views).
• Rules would manage all conditions / actions things of drupal, with a big panel of possibles conditions and actions for ubercart to manage complex discount, complex shipping etc.... out of the box
• There would be VAT management in core to stop to fear when you begin an ubercart project and you are european

I finally would add that even if I write a lot of things when we talk about Ubercart improvements, this is an awesome project made by an awesome team. Congratulation guyz, you made somethings very good and creating a nice community around it.

I will continue to follow this project, for sure

What I would really like to see in the next version of UC is a better integration with tools that are already built and tested (CCK, Views, Rules) and better communication between UC maintainers and maintainers of these good modules. I think solutions like Catalog and CA already proved that they aren't the way to go. It is sad to see that Ryan and Lyle still have CA in their to-do list for UC 3 instead of Rules. I still don't see Views in that list which is also a big surprise for me because it is so damn better than Catalog - many times better in terms of flexibility, themeability, support and so on.

I'm also thinking that if we adopt these modules then their maintainers and maybe part of the community around them would hook in and try and help out(when we need it) - there is already a post here where Fago expressed his support for Rules integration in UC, back when UC2 was being developed.

Trying to make UC more user-friendly is a noble idea (which I support) but don't forget that Ubercart users are Drupal users in the first place - most of them already used with popular modules like CCK, Views and probably Rules (if not they will get). So having custom tools like CA and Catalog to replace those modules is bad for Clients and specifically for developers.

• Better API
• Better documentation
• Rules
• Views
• Support for dynamic attributes (please)
• Me doing my best to help Ubercart become a better Ecommerce solution
• Learn from others mistakes (other OS Ecommerce solutions)

This is what I don't agree with

• User-friendly CA UI - we can help Rules be friendlier instead of reinventing the wheel
• Catalog - Views is better, more flexible and better support, documentation, etc

I'm actually not sure if this is in UC2, been working (too much) on UC1 installations lately, but I would like to see a hook for when you change an order item. Or is there already an easy way to identify a changed/added/deleted order item and act on this?
Operations which I'm faced with now when user or store admins change order items (products) on submitted orders:
- credit part(s) of a credit card transaction
- increase / decrease stock on items
- submit changed/new data to ERP system

Other than that UC kicks so much a##, that I don't think anything needs to be changed... Ever! *cough* =)

I know that we have done a lot of small hacks in UberCart core on several of our projects.
From the top of my mind I can remember that we added a check box to every line on the admin/store/orders/view page. So that a store admin can change the order status of several orders at a time - been very useful on high volume sites.

In addition to all the great suggestions above, I would like to add/second a few that spring to mind:

1. orders
- ability for customer to add comments to an order after checkout. Useful for adding info like e.g. manual payment details made to a bank offline, etc.

- ability for customer to pay for an order (or invoice) when created by admin

2. multi-currency in core?
- with ability to maintain historical purchases at the historical rates.

My current wishlist:

- Ubercart needs better internationalization capabilities (a shop with 2, 3 or more languages) that can be easily used and activated. The current ubercart localization project is not very good and not actively maintained.

- Develop "other" paying methods, so the webmaster can totally customize the way of collecting payment.

Hey Ryan et al. Congrats on Ubercart 2. It's been a breeze to implement, and scarcely lacking a feature I can think of.

Question -- With D6 is your "essential" focus, do you think you're preventing deep architectual goodness in the D7 branch, if you have to dumb some things down to work the same in D6?

To put it another way, my immediate reaction was shock that you don't just let UC2/D6 stabilize and focus exclusively on D7. Reading further I understand a bit better, but the feeling still persists.

Anyroads, I wish ye well

First and foremost,

1. The most important item to address should be the database normalization and standardization. This is a database driven application...
a. Uc_orders stores the address I think at least 3x.
b. weight/currencies are not stored in a base item format.
U3 should really be set on the minimalist element of the number system such
as grams or ounces or dollars and francs.
c. Products and pacakages and such should be referenced from the node, and not
node themselves. Thus, allowing a more traditional, more workable dataset to be used.
d. Users that wish to use other systems for stock management, accounting, etc..
should be able to interface with an abstract driver to their existing systems.
2. Product & Attribute Dynamics
This concurs with the aforementioned normalization of the db. Attributes and other product attached items should be able to dynamically be added to each product.
3. Core APIs for basic store functions.
4. Documentation, Documentation, Documentation
5. Code Standards, Code Standards, Code Standards. Comments, E_ALL, E_STRICT, Read some of the core code, and try to explain what happens.
6. I have a list,