Convert shopping cart block and form Views to use Views block / page displays

Attaching patch...

This should actually be moved to the Cart module's Views integration since Order isn't dependent on Cart.

Whatever happened with this? Anything I can do to help?

The main thing was just moving the final hunk to the Cart module instead of the Order module. Would be happy to get it in. : )

Tagging. Not much more to do here.

#3 didn't apply even when it was written...

For the purpose of 1.1, I've simply committed the default argument plugin that will enable users to create their own cart Views without depending on the Cart module to pass the current user's cart order ID. I'm going to repurpose this issue to be used later for converting our default cart block and form Views to use an actual Views block display and page display, but I hesitate to make such a sweeping change right now. I'm not sure the Views form functionality is ready for it, and I want to do both of them at the same time. : )

So, incremental commit: http://drupalcode.org/project/commerce.git/commitdiff/51e16a1

Just a quick note that I did revisit this issue prior to the 1.2 release. Converting these to use Views is a fairly trivial update, but I didn't have time because of the security release to actually sort out what the upgrade path should be for people who are using the default cart block. It may just require a manual change and a time where we leave both around for existing users or something... that needs to be solved and then we can get this in.

For the cart page itself, we probably won't need any sort of upgrade path.

Tagging for 1.3; still not a blocker, but if we can figure out the update issues in my last comment, let's get it done.

Here's a rundown on the attached patch:

• Update hook to pass along all shopping cart block configurations to their Views counterpart.
• Removed manual "cart" menu item and associated page callback.
• Updated a couple of hook_form_alters to avoid adding submit buttons to cart form when cart is empty.
• Added hook_block_info_alter() in order to provide sane defaults to Views shopping cart block.
• Removed hook_block_info() to remove UI for existing shopping cart block. Note that hook_block_view() was not removed in order to not break sites who have manually embedded the shopping cart block in their custom code. The block is now deprecated as of 7.x-1.3.
• Conditionally add shopping cart stylesheet in hook_preprocess_views_view()
• Added an area handler to render empty shopping cart themes. Used in "No Results Behavior" in both page and block views.

Both 'commerce_cart_block' and 'commerce_cart_form' views have unmodified default displays, but have added block and page displays, respectively, which use the "Empty shopping cart" area handler, as well as the Order ID default argument plugin added by Pedro in #12.

Talked this over a bit with helior on Skype, and the main problem with its approach is in the update process. We're adding a new block display to the cart block in the default View, but if someone has customized this View at all on a site, changes to the default View will not be reflected in the View on that site. However, the update function currently updates the block table to put this new default block in the place of the old block.

I think we basically have two options:

1. Force people to deal with the change, meaning they must be prepared to revert and re-apply their customizations to the cart block.
2. Leave the current block in place but deprecate it and add the new block display as a disabled block. In this case administrators would be responsible between 1.3 and 1.5 to make the necessary updates as opposed to making them immediately.

I think option two is going to be the better approach, because we just don't know what hardship forcing this update may cause. The only reason I float option one is that #1098028: Improve the markup of the checkout review pane. has already introduced a disruptive change to the checkout process in cleaning up the HTML of the checkout review pane. Still, this seems a different sort of change that could leave sites broken instead of just potentially unthemed.

If we go with option two, we can introduce a conditional update function that goes ahead and makes the current change in blocks if we determine that the default cart block View has not been customized at all. In that case, we'd know that the new block display would be detected when the update was applied, because the default View would be brought up to date as well.

Leaving both blocks in place for a couple versions just introduces a usability issue in that there will now be two shopping cart blocks appearing on the blocks page, but it's either this, be disruptive, or postpone this entirely until 2.x. Perhaps we can add some indication to the block list / configuration page denoting the shopping cart block as deprecated and pointing to the new standard instead.

I mentioned this at the bottom of #1022736: Add to cart: Can only flip STRING and INTEGER values! in DrupalDefaultEntityController->load(), but while testing around with creating custom page displays for shopping cart forms, I determined that we still need the form alterations provided by your patch above in core to prevent the cart form View from including submit buttons when the View is empty.

Here's the curated patch that includes just the form alters and the empty cart area handler.

OK, seriously guys..

Oh, forgot to remove the redundant call to drupal_add_css() for the cart page.

Alrighty, I committed the patch in #21 and am just recategorizing this issue to reflect the decision to make a contributed module some day that encapsulates the cart block and form entirely in Views instead of making the changes in the 1.x branch of core.

any news on this? :)

I have created a contribute module that provides an alterative approach that keeps the existing embedded view method and gives a way to override the view that is rendered on the /cart page.

http://drupal.org/project/commerce_cart_view_override

You da man. : )

Problem is that we are not able to access an order id in a custom view. So i can't create a custom cart, invoice or something else.

You can using a contextual filter that defaults to the current user's cart order ID. The bigger issue is preventing a user from putting an alternate order ID into the URL and having the contextual filter use that instead.

#16: cart-views-1030128-16.patch queued for re-testing.

This was removed on purpose. Please leave this postponed; it will be changed in 2.x.

And when will that be? The 2.x. release I mean

We'll be opening the branch for development after the feature freeze for Drupal 8. Right now we're waiting to see what core tools we'll have to build on before diving into the port. : )

It's fair to say that this isn't going to be fixed in 1.x.