Sounds good! I have one question, though. I don't quite plan on moving to Drupal 6 until the majority of our site's modules have been ported (whether that's by myself, with my help, or otherwise) or I have found suitable replacements.

What does your roadmap mean for the 5.x version of Ubercart? Will it be ditched in favor of the migration to D6?

Thanks for all your hard work Looking forward to more coding and testing.

Great to hear a definitive list of things on the radar screen/updates to be made in the near future. I like the idea of getting a working UC for 6.x up before serious "streamlining" occurs because as a commercial user of the product, having the ability to implement the system is more important than having the "ideal" system to implement.

Finally I was wondering if (speak of ideal) there is any chance we might be able to add "productization" to the list of things on your radar. The ability to eventually productize any node type would be a great boon to UC in the long run.

Great Update, Thx,

Eclipse

• Addresses separated from orders.
  Totally agree, it will be more user friendly and will bring more possibilities about workfow and conditions, I hope it will not break the actual user database and it will be possible to import actual customer database in the new system.
• VAT support in core.
  Totally agree, as an european seller, VAT is the things that bring me the most difficulties to configure, If some advices for an european seller is needed, don't hesitate to ask me.
• Allow folks to switch to multi-page checkout.
  It could be a cool feature, but I'm afraid that it would make the creation of checkout related module extremly complicated and will bring a lot of bugs or will bring a lot of code, just for that things. If you make a magic hook that automatically manage all things, why not . But for me it's not a critical issue (true core discount possibilities module would be prior to me)
• Separate validation from submission for checkout panes
  Not sure to understand about that, I thrust you ^^
• Actual store administration theme
  Not sure to understand too, if it's to retheme administration, why not, but I already find it very good.
• Better support for internationalization, including core VAT support.
  Totally agree, internationalization is a credo of drupal 6, it should be a credo of ubercart
• Remove uc_notify.module and replace it with conditional actions.
  Totally agree, with workflow, drupal 6 actions etc.... there is enough possibilities to manage notification in a more powerfull way than the ubercart notify module
• Fix cart pane API Smiling
  Agree
• Separate Views integration out into its own module.
  Agree, I would add to bring some efforts about it. Like adding more fields (especially attributes related, more arguments, more all ^^). I say that for 2 reasons :
  • Actually, the catalog module is good for a people that quickly want a catalog in the oscommerce style. If you want something more extensible, more easy to maintain, you will use views, and the ubercart views integration is too light today.
  • Views will come into core with 7.x version of drupal, working on a great views integration will save some work later ^^

  For that reasons, I think it's more logic to bring efforts in a really good and complete views integration and let catalog module beeing a third party module that bringing a catalog module into core and make core views integration anecdotic.

• Get the rest of the manufacturer trappings out of core
  For sure
• Try to get rid of any other module_exists checks, too.
  Don't know what's the problem with it, maybe performance issue... I thrust you ^^
• Move Store Links block out of core and into a contrib module.
  Yes, good idea
• Invoice templates should be overridden at the theme level, not in the module dir
  Totally agree, and I would generalize for all module as you said. I would love to see some .tpl.php files to overide checkout page/panes pages etc...
• Update stock support.
  Totally agree, it is a critical need for most shop, and the Cpill module is not maintained anymore, I would see more possibilities for the core stock module
• Review line items API.
  Agree agree agree, it still need some work for about performances and bug
• Core conditionals system
  Not sure to understand, does it mean the end of workflow ? Will you replace it by the core drupal 6 action and trigger module ? Or will you adapt Ubercart 2 to the new rule module (that is the next workflow-ng) ?
• Simpletest for full unit test coverage.
  Don't know how simpletest work, it seems good ^^

I would add some personal questions for next releases :

• Do you plan to continue support for catalog module ? I know it is pretty out of the box for a simple shop, but I can be easily replaced by some others modules like views, taxonomy list, taxonomy image...
• Do you plan to add more reports on the reports module, if yes, but if you are out of ideas of what could it be added, I have a lot of commercial and marketing people that work with me, and I can ask them what they would see

Thanks, zmove. I don't have a much better answer than the one I'm sure you expect... hopefully it'll be done by then, but there's no way to know.

My goal would be to have something to demo at Drupalcon Szeged, assuming we can make it. We're well underway, we just haven't had a chance to get things in a good state for testing and collaboration. Hopefully that'll happen sooner rather than later.

Even as a non-coder I can clearly see Ubercart, together with Drupal, is a cool set of scripts with amazing flexibility. Thanks so much to all developers, testers, document writers etc. for your hard work, appreciated!

I can see a lot of interesting new features and reorganizing of code in the road map above. Hopefully all this development makes it possible to build a gift shop, where one can buy gifts in one order to different people with different delivery addresses (thinking about making it easy to buy Christmas Presents, for example, to several people at the same time)

Keep up the Great Work!

I wouldn't make any movement on that particular feature without making sure you were in the loop. If it happens, I'd try to grab you for a chat on how your code can best fit into core or how core could best accommodate a module like yours to provide extra functionality that might not be needed in core (like a separate address book). Something like this wouldn't get into 2.0 given the dev. roadmap, though, so don't sweat being busy right now.

any idea about when to expect an ahah powered ubercart release?

we'd love to see some more ajaxy stuff

The most time-demanding (and monotonous) task is the addition of all the product data, at least with a site that will contain 300+ items. So I am wondering - Can I, and how could I best, develop my content so as to leverage my product data for use with a future, 6.x release of Ubercart?

I'm referring mostly to custom content-types via CCK, and perhaps categories as well. Are there any recommendations for my pursuing a site development path like this? Is it possible to do without a crazy amount of headaches when integrating Ubercart into my 6.x site containing perhaps hundreds of nodes on a custom content type?

I like that you have many many improvements on the list, that is the real Drupal thinking. http://www.lullabot.com./articles/drupal-community-philosophies

I would like to help with the internationalization. The dynamic string translation is not solved, not even in drupal 6 core. Will try to find a best way for doing this, or give suggestions at least, but don't want to spam this forum with an i18n discussion now..

Bringing up the subject of uc_addresses again...

Someone has tried to upgrade the uc_addresses module to D6. They are using Ubercart 6.x-2.x-dev. The question I have is: as the module owner, should I officially support a D6 version of the module?

The problem comes from thinking about the future of addresses in Ubercart. There's been talk of making addresses a core feature. What I've been thinking is that addresses should be a custom node type, just like products. The module I finished works nicely but doesn't offer the extensibility it would gain if addresses were nodes. So the future code for addresses would be quite different than what I've implemented, at least on the inside.

The road map, if I understand it properly, the D6 version will be a clean-up but not enhanced version of Ubercart. D7 will have the enhancements. So I think a straight port of uc_addresses to D6 is OK, and the D7 version should be the one to consider integrating addresses. Just want to make sure my reasoning is OK.

My quick thoughts... a major change like that would be slated at least for UC version 3.x. We're targeting that for release on Drupal 6 toward the end of the Drupal 6 development life cycle.

I just tried installing the D6 version and now the Modules page comes up blank every time.
After I go in and manually drop the uc_* tables in MySQL and remove the ubercart directory the page comes back up just fine.

Is there a way to totally back out any initialization changes that happened during the module install?

What parts of the modules are enabled on the test D6 website?

Also, forgive me if this is in the wrong place.

Thanks!

Thanks for stopping by and giving your input.

I think I'd stand by the theme layer for the invoice templates for two reasons...

1. It makes practical sense, as you don't have to worry about accidentally deleting your custom templates when you update your Ubercart version.
2. The theme layer in Drupal consists of two parts... templating the layout of elements and addressing the appearances. The former is done through .tpl.php files and the latter through your style.css. So, the modules expose the data, the .tpl.php will output the HTML, and the .css will add the appropriate styles for further positioning and presentation. Obviously the modules will define the components available to the invoice, but the .tpl.php will define how those components should be displayed on the page. This is normal in Drupal and is done for things like node displays. What Drupal 6 allows us to do is ship a .tpl.php file with a module that can be overridden by anyone in their theme with a .tpl.php file of the same name. So, we'll still be shipping invoice templates, but it will be a little easier for folks to modify and maintain their own invoice templates. The alternatives are either to keep it like it is w/ custom files in a module directory that may accidentally be deleted on update, only allow invoices to be defined in custom modules which makes it significantly harder for folks to adjust, or force people to hack core.

Totally, but the same will apply for what's e-mailed, because at the moment you can send an HTML e-mail of the invoice from the site. So in Drupal 6 you can call the same theme function that would display it on the site to add it to the body of an e-mail... alternately, you could just use the UI to create a fully text version of the invoice for e-mailing. Honestly, I'm way tired of the current invoice template and hope to see that change sometime soon.