Bug Can't remove items from cart on checkout page if it has required fields

[benFF]

If you have any items in your cart which have required order fields - you then cannot remove that item (or any other item) until the required fields have first been filled in.

I thought adding a simple formnovalidate tag to the delete button would solve this - and whilst it does let the form submit, then the backend validator fails it.

 

[benFF]

Whilst you're looking at the checkout - I suggest that maybe it's a better idea to put the custom order fields above the purchase options, so they're next to the actual items they are linked to.

Most orders don't use a coupon, so it's a bit strange to have to scroll past that just to fill them in.

 

[benFF]

Oh and finally, also related.

The purchase ux is not very intuitive.

When you click the original "purchase" button, the modal gives two options "add to cart" or "checkout"

Most people would assume you need to add to the cart before you can checkout, so they click that and are then returned to the original page, very confusing.

The checkout button text should be changed to "buy now" (or get now if it's free) and I think the icons swapped (shopping cart for add to cart and credit card for buy now)

This is how the original bug above was discovered. Users clicked add to cart, redirected, then clicked purchase again, but this time "checkout" - which of course meant they had two items (which then couldn't be deleted)

 

[benFF]

It gets even more bizarre - if you two or more products to the cart and then try and delete one, it will force me to accept the terms of service, then automatically submit the order and forward to the payment page!

I thought it might be a template edit I made, but I reverted them all now and it's still doing it.

 

[Fillip H.]

The following changes will be made with v4 for XenForo 2.3:

• Most credit card icons have been changed to a cart icon
• The "Checkout" button in the purchase overlay has been renamed to "Express checkout" (new phrase)
• Moved VAT information above Coupon/Store credit
• Each part of the checkout form now has a separate block
• The "Order fields" block now has a block header with the phrase "Required information" (new phrase)
• The "Required information" and "Purchase options" blocks now have their own Save buttons
• It is now possible to update item quantity in your cart on the Checkout page without filling in required information
• It is now possible to delete items from your cart on the Checkout page without filling in any required information
• It is now possible to update Coupon code/Store credit on the Checkout page without filling in any required information

Here's a preview screenshot of the new Checkout page:


This does have one downside; the entire form will no longer be saved when pressing any of the individual save buttons. When pressing "Proceed to payment", it will save & validate the entire form, but otherwise, only the button next to the block in question will save that particular block.

I don't believe there is a way around this without running into the same form validation issue.

Is that an acceptable compromise in your eyes, or do I need to look into alternate solutions?

 

[benFF]

Hi Fillip,

Looks good - I have been going over a lot of the UI/X in the last week or so as my order completion ratio was abysmal (1 in 10).

I think you have touched on basically everything I found, but yes I did the following:

On the overlay - changed the checkout text to Buy Now. I think I also swapped the icons around.


Then did as you have, put the product options just below the item list, then the purchase options below that.

I then removed the scroll of text for the terms and conditions and changed it to a modal, with just the checkbox:


Finally I moved the save button to below that and next to the payment button, renaming it to "Update cart"


I think your solution with multiple save buttons should work, I will probably change the phrases though.

However the biggest change that I made was backend. The current system works well if you are registered, but if not, the flow is terrible and many customers are lost at this point as when they fill in their registration forms, they are either:

1) If no email validation required, they are taken to the default XF page that just says thanks for signing up.
2) If email validation is required, as soon as they click the link, like above, they are just taken to a default XF page.

At which point, non-technical minded people have no idea what to do.

To get around this, I extended the following controllers:

Register

    public function actionComplete()
    {
        $reply = parent::actionComplete();

        // If the user has something in their cart, we will assume they are just signing up for a purchase, in which case redirect directly to the shopping cart
        $visitor = \XF::visitor();

        if ($visitor->user_state == 'valid'
            && $visitor->canViewDbtechEcommerceProducts()
            && $visitor->canPurchaseDbtechEcommerceProducts()
            && $visitor->getDbtechEcommerceCartItems())
        {
            return $this->redirect($this->buildLink('dbtech-ecommerce/checkout'));
        }

        return $reply;
    }

AccountConfirmation

    public function actionEmail(ParameterBag $params)
    {
        $reply =  parent::actionEmail($params);

        $visitor = \XF::visitor();

        // If $view is a typeof view AND something in the cart, then it was a successful login, so redirect to checkout
        if ($reply instanceof \XF\Mvc\Reply\View
            && $visitor->user_state == 'valid'
            && $visitor->canViewDbtechEcommerceProducts()
            && $visitor->canPurchaseDbtechEcommerceProducts()
            && $visitor->getDbtechEcommerceCartItems())
        {
            return $this->redirect($this->buildLink('dbtech-ecommerce/checkout'));
        }

        return $reply;
    }

Since making all these changes, the failure rate has dropped considerably and at this point I think it's just down to people backing out, rather than an issue with the cart flow

 

[Fillip H.]

Interesting, I had no idea there was no dynamic redirect. I’ll steal those extensions and implement them into the core