Hello,

first: Thank you for Ubercart, and also
for the improvements that have been achieved in the D7 Version of Ubercart!

My Question, although it might be a little early to ask this, is:
how far are the plans for the porting of Ubercart to the upcomming D8 ?

Comments

Last I heard, Drupal 8 was expected to be released around August 2013 and is under very active development. I wouldn't expect an Ubercart port to D8 to start until things settle down a little.

It will certainly have to happen, though.

Status:Active» Fixed

Yes, it will happen. But it's premature to put a lot of effort into it right now because D8 is still undergoing major changes and keeping up with those changes is way too much trouble right now for the few volunteers who are working on Ubercart. I know this from first-hand experience; one of my modules was the third module ever to have a port to D8, but that module broke several times every week as changes were made to D8 and it became a full-time job just to try to keep it running. So I've stopped trying until D8 is a little more stable.

Hey TR

Will this be a straight port of UC3 to D8?

Not sure yet.

Version:7.x-3.2» 7.x-3.x-dev
Category:feature» task
Status:Fixed» Postponed

I think this should stay as a postponed task until we release a D8 version of Ubercart.

I imagine a D8 release will be largely a straight port, but hopefully will take better advantage of features such as entities, configuration management, etc. similar to how the D7 release was an incremental set of improvements over D6. If there are any specific feature requests for D8 that we cannot implement easily in D7 as they would break compatibility, I guess this issues is as good a place as any to request them.

One thing I have thought of for a while is dropping the idea of "cart panes", making the cart page a standard form (or view?) and converting the shipping quote cart pane into a block, allowing it to be used anywhere. There have also been requests on ubercart.org to unify checkout and order panes, which I think is a good idea, but would be a considerable change to the existing API.

I would also like to see more Rules integration, but on the other hand, it seems there is no movement yet towards a D8 version of Rules, and by the looks of things that will be our sole dependency now that Views and the improved Entity module are in core.

Requests:

Heavy API and UI support for shipping modules. Make it so that the module can define unique things like special fields and a function for generating a shipping label, but Ubercart core does everything else, especially the UI. Shipping modules shouldn't be supplying forms. Make everything an entity with hook_..._alter() calls as they're loaded. Add automation to fill packages (I know it's impossible), and generate shipments. Add package packing slips. Add batch generation/printing of shipping labels. Add automation options for everything possible to reduce the number of clicks required. Include tare weight. Oh, and the package data structure should store the weight. Add a serialized "data" field to the shipment and package DB tables so other modules don't have to maintain parallel DB tables if they have extra information.

Drop the whole concept of a shipment object. Just store all relevant information per package. Setting up a shipment is just extra clicks. Do allow multiple packages to be shipped at once, though.

Basically, I'd like to be able to click once on a button that says "print shipping labels". Ubercart would then find all the orders that were ready to go, create shipments, create packages, and produce a batch of shipping labels, then change the state of the orders as appropriate. Anything it couldn't figure out, it would hand back to the administrator for manual intervention. If most of your orders fit into one box, this would help a lot.

Add a technique to turn any node type into a product. Add the Ubercart-specific fields.

Automatically search for and register templates for everything. Right now, it's pretty hard to use a custom invoice template, for instance.

Related to the earlier one...make the package structure an entity so that Rules can make decisions about them, especially their total package weight.

Anything that can be a view, make into a view.

I'll come up with more later, I'm sure.

Address system improvements
This probably wouldn't come as a surprise, but my suggestion would be to improve the address system in Ubercart for Drupal 8 and allow extra fields to be attached to an address (such as house number). Perhaps the Address Field module could be used, although I haven't checked that module for a long time now and I'm not even sure if it allows you to add extra address fields easily. Other possibility is to take some ideas from Ubercart Addresses, especially how it handles address formats (formats are build by using tokens, instead of "hard-coded" variables). This can be further discussed in #850630: Incorporate uc_addresses into Ubercart or allow address system to be extended.

I'll throw my $.02 in. UC should stay as an almost RTR solution for the non developer users. There are a few things that would make it more easy to use out of the box and more inline with other OS shopping carts.

I'd like to see the Add To Cart form be separated into separate buy button, attributes field(s) and quantity fields that are available to Views. This would also work into this problem http://drupal.org/node/1835206 especially with attributes and quantity field.

A lot of people over the years have wanted a simple price field for "on sale" items. Not sure how this would work with attribute pricing. I know it can be done fairly easily with views and extra field and CSS but its not end user friendly and only really works with products that don't use attributes as price adjusters. I think this is an essential feature as most carts already have it built in core.

It's probably too soon now, but it would be a good idea to announce a date at which support for Ubercart 2 will be discontinued. This will probably be linked to cessation of Drupal 6 support, of course.

Three months of advance warning would be minimum to allow for migrations. Six would be better.

Re-do the stock/inventory system to (optionally) track items with different attributes separately. Enforce unique SKUs to support this. But you knew that.

Transform many records into entities, probably fieldable. Here are some possibilities. Mention more, and I'll add them to the list.

Payment receipts.
Quote methods.
Shipping methods.
Anything with a serialized "data" field.
Packages.

Transform all tables into Views. Some examples:

All the reports.
Shipping quote methods.
Shipping methods.
Payment methods.
Package list (global, and per-order).

Another things that should be looked into although its not a UC core problem is to have someone create a nice theme something like this http://demo.weebpal.com/#ishopping that would be ready when the D8 UC is released.

change payment method,shipping method, checkout pane to plugins system.

Make the whole Ubercart state easily exportable and importable.

A lot of commercial "themes" are actually pre-built, pre-configured distributions that are set up already. You build your modules, data, and customizations on top of them. That's fine, but...

If you've already set up Ubercart on a development site, there's no easy way to move it onto a pre-built or otherwise pre-existing site. The state is kept in a plethora of interdependent database tables and Drupal variables.

Make it so you can somehow export the entire state and configuration of Ubercart, then take that exported state and install it on another host.

Add options to make it more fine-grained. Maybe only export or import the configurations for certain modules. Maybe skip the orders. Maybe pass on exporting the product nodes.

Priority:Normal» Major

Will this be a straight port of UC3 to D8?

Not sure yet.

I am going to be direct here: Ubercart 8.x-3.x may well be a death sentence. UC 7.x-3.x already lags behind Commerce 7.x-1.x, both in features and users. If Ubercart wants to survive, it will need to be mostly rewritten. Ubercart 8.x-4.x has to make as much use of Symfony2 (routing, event handling, validation) and Drupal 8 (moar fields, moar entities, entity references!) as it can in order to compete. These features are awesome, flexible, and help Ubercart's users make Ubercart better for you.

I don't want to pick a fight, or to set the Ubercart and Commerce camps up against each other. However, a little competition in the field of e-commerce is probably not bad for development. It keeps people on their toes, and helps Drupal become a better overal e-commerce platform that can compete with dedicated solutions.

Also, and I realized this this morning when comparing Commerce's and Ubercart's PayPal support: you may want to strip Ubercart of payment and shipping plugins, and maintain them in separate projects. PayPal, for instance, has released some API updates that cannot be incorporated into Ubercart's PayPal modules, simply because that would require a new major UC release and nobody wants that. Lastly, and this is my main reason for being concerned with both Ubercart and Commerce, take a look at the roadmap for Payment 8.x-2.x, and and Currency 2. It may be worth leveraging third party modules like these if you want to remain competitive.

Bumping to major, because a Drupal 8 release should not be underestimated.

I would also like to see more Rules integration, but on the other hand, it seems there is no movement yet towards a D8 version of Rules, and by the looks of things that will be our sole dependency now that Views and the improved Entity module are in core.

Drupal core is to get a few features that will benefit Rules. See #1743686: Condition Plugin System, for instance.

Do you think who will win the battle? Ubercart or Commece?

It's not a battle, and I wouldn't want either platform to win. Both platforms have their pros and cons, and I'd like the 'competition' between them to encourage innovation and progress.

I do fear that, looking at recent Commerce developments, if Ubercart doesn't speed up and embrace Drupal 8 to the fullest, that there will be no need for a Drupal 9 version, and that would be a shame.

I think July 1, 2013 would be a good date to start with a port to Drupal 8. If I'm right, at that date Drupal 8 reaches code freeze, so from then on I think it's stable enough to develop for. See also comment #2 for why the port to Drupal 8 is currently postponed.
Postponing this also allows Ubercart developers to concentrate more on fixing bugs in the 7.x-3.x version. I think: the more bugs are fixed, the less time it would take to also stick time in the Drupal 8 port. Because if there are less bugs to be fixed, more time can be spended on the port.
The downside of postponing this, is that it would probably not be realistic to get a stable release out shortly after the first stable release of Drupal 8.

Posted by Xano on February 25, 2013 at 2:59am I am going to be direct here: Ubercart 8.x-3.x may well be a death sentence.

Lets hope not. if so then no commerce for me, I'll stick to the standalone OS carts that are out there. Some of the DC owner/dev comments and statements left a bad taste in my mouth so no thanks.

I'l see how my funds fare in the next three months maybe I'll be able to sponsor the start of the conversion/rewrite.

Posted by Xano on February 25, 2013 at 2:59am I am going to be direct here: Ubercart 8.x-3.x may well be a death sentence.

Lets hope not. if so then no commerce for me, I'll stick to the standalone OS carts that are out there. Some of the DC owner/dev comments and statements left a bad taste in my mouth so no thanks.

That's why I suggest building a 8.x-4.x version, and NOT 8.x-3.x. Ubercart should IMHO be totally revamped to make use of everything Drupal 8 and Symfony2 have to offer. This is what Commerce 7.x-1.x did with Drupal 7, and that's what made it so successful: it has usable modern features, which make it extremely customizable and extensible. A robust, modern, and extensible code base is what makes a platform successful these days. Don't do things exactly like Commerce does them. Do them your own way, but don't forget to, even if you want to target your UI to newbies/less demanding site builders, allow other developers to easily change the way Ubercart works.

A few very basic suggestions:
- Don't use arrays when objects are appropriate. This way, developers can leverage type hinting, Symfony2's validation API, and it makes documentation easier. Ergo, DX++.
- Make at least important features pluggable, even if you ship with only one default plugin. This removes assumptions, and, allows other developers to make Ubercart more awesome for you. DX++.
- Split off functionality that doesn't belong in Ubercart core. Adding shipping or payment methods that are not generic and depend on third parties (such as Fedex and PayPal) imposes limitations on how agile you can develop. Instead, put them in separate projects. Say PayPal updates their APIs, you can release a new PayPal version, without having to update Ubercart core. It also allows people to work on the different projects independently, speeding up development. Development speed++/work load--.

As the Drupal 8 core APIs are not yet stable, the time may not be right yet to actually start coding a new version, but now that we're in feature freeze, plans can be drawn out so that when the core APIs become stable, Ubercart developers have clear goals and can start coding right away.

Frankly, the thing Ubercart needs for Drupal 8 needs more than anything else is a bigger team of developers. The people who work on it are talented, dedicated, helpful and attractive, but there just aren't enough of them.

As it is, Ubercart 3 has a big backlog of tasks. It would have been nice if they'd been done a year ago. There are still modules that haven't been ported from Drupal 6. A full rewrite and port to Drupal 8...that's pretty big.

I think we're going to have to pay people expressly to work on the project.

This is a tricky puzzle because the cart is mainly used by small businesses who are not in a position to hire a full-time programmer. Also, a lot of them use the software exactly because it's free.

So, where will the money for that come from? Well, there are a lot of such businesses. Maybe there's some way to set up a consortium. If just 1% of the businesses who use the cart each kicked in $1000 per year, that would be enough to hire a full-time developer or two.

So, where will the money for that come from? Well, there are a lot of such businesses. Maybe there's some way to set up a consortium. If just 1% of the businesses who use the cart each kicked in $1000 per year, that would be enough to hire a full-time developer or two.

I can't see enough businesses willing to fork over each $1000 per year to UC. Most of the sites are small and that much money would be a big chunk for them.

Except for donations I have no idea on how you could get funding for more dev hours.

UC needs to distinguish itself from DC. Being a stand alone, ready to go cart for small retailers is what it should be and not some monster framework which only dev's could care about.

Personally if I didn't want to have extra content like forums and articles on my sites and just a straight shopping cart site I wouldn't bother with either UC or DC are there are tons of OS carts out there that are much more supported.

Keep it simple yet extensible through Drupal modules. Having documentation on Drupal modules that can enhance UC out of the box would be a step in the right direction.

Also maybe there should be a node--product.tpl.php file included with UC that has all the necessary variables in it so people don't have to hunt around the forums if they want to customize the product page layout.

Frankly, the thing Ubercart needs for Drupal 8 needs more than anything else is a bigger team of developers. The people who work on it are talented, dedicated, helpful and attractive, but there just aren't enough of them.

As it is, Ubercart 3 has a big backlog of tasks. It would have been nice if they'd been done a year ago. There are still modules that haven't been ported from Drupal 6. A full rewrite and port to Drupal 8...that's pretty big.

I think we're going to have to pay people expressly to work on the project.

If there is more work that can be done, then either capacity should be increased, or the work load should be lowered. This is one of those situations that stimulates people to look critically and increase efficiency. As I explained before, Ubercart core contains too many specific features that depend on third parties that increase the work load and make it hard to stick to release schedules AND keep the code base up to date. My suggestion is to cut all these features from Ubercart core: payment methods, shipping methods, Google Analytics, etc. This will allow the developers that we do have to focus on Ubercart's real core.

Another way to decrease the work load is to reuse existing modules where possible. This goes for the fundamentals (use entities and entity references), but also for more application-level features: Rules is already used for configurable behavior. Use BCMath for high-precision calculations. I made Currency and Payment for this exact purpose: they do one thing, and do it well, and this allows other projects to leverage these modules without having to bother with specifics themselves.

UC needs to distinguish itself from DC. Being a stand alone, ready to go cart for small retailers is what it should be and not some monster framework which only dev's could care about.

Personally if I didn't want to have extra content like forums and articles on my sites and just a straight shopping cart site I wouldn't bother with either UC or DC are there are tons of OS carts out there that are much more supported.

I don't believe this is true. We have come to a point where it matters how extensible your applications are. Maintainers are no longer able to provide everything people want. Instead, applications are made pluggable, and everybody can create plugins. This is what happened to Commerce: they reused existing, pluggable APIs, and they let hundreds of other developers provide their own plugins. This is a basic philosophy that does not have anything to do with UC or Commerce. Structuring UC this way lightens the maintainers' work loads, yet provides UC with enormous potential. It also allows the people who work on UC directly to easily add new features to UC core itself.
The UI is a different story. Ship with sensible defaults. UIs can be overridden by other modules, so they are less of a worry.

Keep it simple yet extensible through Drupal modules. Having documentation on Drupal modules that can enhance UC out of the box would be a step in the right direction.

Also maybe there should be a node--product.tpl.php file included with UC that has all the necessary variables in it so people don't have to hunt around the forums if they want to customize the product page layout.

Exactly! This is part of making a project easily extensible/customizable. It should not only be possible at all, but also as easy as can possibly be. Documentation helps. Using classes instead of endlessly nested associative arrays helps too.

Xano wrote:

Another way to decrease the work load is to reuse existing modules where possible.
...
I made Currency and Payment for this exact purpose: they do one thing, and do it well, and this allows other projects to leverage these modules without having to bother with specifics themselves.

This is a good idea in general. Consider not just the competition of Ubercart and Commerce, but Drupal and all the other platforms out there.

My suggestion is to cut all these features from Ubercart core: payment methods, shipping methods, Google Analytics, etc. This will allow the developers that we do have to focus on Ubercart's real core.

I like this idea, but there still need to be developers to maintain those modules, even if they are compatible with non-Ubercart modules. This may decrease the pressure on the Ubercart maintainers, but the overall workload won't go down.

end user wrote:

I can't see enough businesses willing to fork over each $1000 per year to UC. Most of the sites are small and that much money would be a big chunk for them.

This is a problem for Ubercart. It is free software that is used by small businesses. If it were used by large businesses, there would be some who could spare a full-time developer, or contribute the money to support one. I'm not sure exactly how to deal with that, but there must be some way.

Being a stand alone, ready to go cart for small retailers is what it should be and not some monster framework which only dev's could care about.

Having something quick, shiny, and easy is a good direction. The framework is less important, so long as it doesn't get in the way of some shop owner stumbling along setting up his Web site.

My suggestion is to cut all these features from Ubercart core: payment methods, shipping methods, Google Analytics, etc. This will allow the developers that we do have to focus on Ubercart's real core.

I like this idea, but there still need to be developers to maintain those modules, even if they are compatible with non-Ubercart modules. This may decrease the pressure on the Ubercart maintainers, but the overall workload won't go down.

That is true. However, by moving these parts to separate projects it will be easier to develop them at different speeds (e.g. keep up with third party changes) or to have them maintained by other developers.

The big one is Drupal 8's Configuration Management.

I don't know much at all about it, but I believe that it makes it so that you can save the configuration of some system and move it over to a new site.

Right now, migrating Ubercart, or any Drupal site, is a real pain. You can buy pretty site templates and build your site from there. However, if you already have a site up, it's not reasonable to apply/migrate that template to your existing site.

I would like to say I am intrusted in a simple out of the box ubercart solution. For more sophisticated, more features, there is drupal Commerce

I can probably donate $200 per month into a pool. I'm past a certain point in by business so can do that atm.

The code freeze is currently scheduled for July 1 (See http://buytaert.net/drupal-8-feature-freeze-extended), with the release some time after that. Is it time to make some announcements on ubercart.org and on the project page here about plans for U4 and U2?

Half the Ubercart sites out there are still running D6. Is it time to strongly encourage migration?

I will be doing a BoF on Payment and Currency in room A103 at 14:00/2pm this afternoon (Tuesday) at DrupalCon Portland. There will be time to answer questions you may have about the modules, and to discuss implementations and future development. We are expecting developers who are writing payment method plugins, but also some who are looking into leveraging Payment for their own modules that require payments to be processed.

The BoF was successful, and attended by a fairly large group of people with different interests (various payment methods, Ubercart, Commerce, Webform, custom integration...). Payment's and Currency's user bases are growing, with more plugins to come in the next few months.

I was also hoping to attend a BoF or session about Ubercart for Drupal 8. Maybe I overlooked it, but I couldn't see any in the schedule, nor on the BoF boards. Has planning on this started already?

Status:Postponed» Active

Is there any plan for Drupal 8? It seems that there will be a beta release in the next month.

So, I finally pushed my private branch of 8.x-4.x that I've been slowly upgrading to Drupal 8 for the past year or so. It doesn't pass all tests yet, but it's a start. Don't expect everything to work by any means, but please download it, have a play, and make more suggestions about what you want to see Ubercart do in Drupal 8.

Development release: https://drupal.org/node/2141275

Longwave you're a trooper, tip of the hat to you. Competition is a great thing for innovation and the keeping the status quo in check.

It is great that ubercart still well living in Drupal8.

@longwave: Awesome! Do you have any plans for payment methods yet? I see you created a plugin manager that just invokes the hooks as we know them for 7.x-3.x, which is a good start. I proposed using Payment 8.x-2.x a while back, but if you decide that Ubercart should keep using its own payment processing platform, I'd like to work together to make sure Payment can at least be linked to it.

Two useful bits of plugin knowledge:

  1. Use ContainerFactory rather than DefaultFactory, so plugins have a container-aware factory method and they can have their dependencies injected. This decouples them from the rest of the system and ensures they can be tested through PHPUnit.
  2. To manage a plugin instance's configuration, make your plugin interface implement ConfigurablePluginInterface. This is also extremely handy for 'importing' and 'exporting' the configuration for storage.

This is great news indeed. Thank you. I'm not anywhere nearly ready to test UC8.x-4.x yet, but the reassurance that it's being actively developed is what I needed to know that I've not backed the wrong commerce module.

You can try out Ubercart 8.x-4.x without having to download or install anything using simplytest.me: http://simplytest.me/project/ubercart/8.x-4.x

@Xano: I definitely would like to support Payment in Ubercart core; just as Drupal 8 is collaborating with other projects, it makes sense to do the same in Ubercart.

I am not yet sure whether Payment should be the only way we handle payment methods, or whether we should have an Ubercart payment API that allows alternatives to Payment as well. As an example it might be nice if Ubercart could also support the methods provided by something like https://github.com/omnipay/omnipay

Thanks also for the hints on the plugin API; the payment method manager was really just an experiment in seeing how the plugin API works and how we could use it in Ubercart, and the code could definitely do with some cleanup.

@longwave: I created #2142579: Drupal 8 version for linking Payment 8.x-2.x to Ubercart 8.x-4.x.