Jump to content

Radio buttons for shipping on checkout


jasehead

Recommended Posts

The issue with the current checkout is that VERY FEW customers understand they can make a shipping selection and instead just proceed with the default setting (which is the cheapest and slowest option). For limited shipping choices, radio buttons would be much better.

In the medium and small checkout pages I want to be able to get radio buttons for shipping working for Cubecart v6.0.12 Foundation similar to this discussion for v5.2.1 - https://forums.cubecart.com/topic/47002-resolved-default-shipping-method/

So far I have this adapted from bsmither to replace the code in content.checkout.medium-up.php starting around line 49:

            <td colspan="4">
               <p>{$LANG.basket.shipping_select}:</p>
				<ul style="list-style-type: none;">
                  {foreach from=$SHIPPING key=group item=methods}
                     {foreach from=$methods item=method}
						<li style="padding-left:14px;"><input name="shipping" type="radio" value="{$method.value}" {$method.selected|replace:'selected':'checked'}" /> {$method.display}</li>
                     {/foreach}
                  {/foreach}
				</ul>
            </td>

It works but it's very rough.

What I need it to do is:

  • Have the $method.display text as labels or links to activate the correct radio button on click (all buttons are being called "shipping" so they should probably be in a group but have unique names so that labels work)
  • Update the page on radio button checked to refresh the estimated postage and total (like the existing select shipping option does on select)
  • Overwrite the two local shipping options to show only one option (Air Mail) if the order is outside my own country - and have that pass through to the order

Then it's a matter of making it pretty, disabling the cheapest-first sort on shipping, and making one radio button already selected.  I'm just working with two options from the By Weight shipping module at the moment.

Link to comment
Share on other sites

If the main issue is that CubeCart defaults to the lowest shipping price, then our Enhanced Sorting plugin (https://www.cubecart.com/extensions/plugins/enhanced-sorting) gives you the ability to say to default to the most expensive option (as well as a lot of other enhanced functionality).

The ability to choose whether shipping options are shown in a dropdown or as radio buttons is something our plugin doesnt do right now but is an interesting enhancement and I am looking at including that straight away.  This would then fix the outstanding issues that you have and also get away from the requirement to change core code !

1 hour ago, jasehead said:
  • Overwrite the two local shipping options to show only one option (Air Mail) if the order is outside my own country - and have that pass through to the order

Incidentally, it should already only show the shipping options that are applicable for the customer based on their address and the store's location.  If they arent logged in then the store doesnt know their address, so doesnt know if they are local or not

Link to comment
Share on other sites

The main issue is that customers DO NOT READ as they checkout and tend to miss that there IS any other delivery option other than the default.  Which is why a drop-down select menu is bad and radio buttons would be better (especially where there are few delivery options available).

Link to comment
Share on other sites

Thank you, but forcing customers to "Please Select" will result in the customer trying to submit their order, receive an error, then having to review the page to find that they have to select an option - any frustration increases the chance of cart abandonment.  I would rather have two shipping options as radio buttons and have one option already selected (either cheapest or most expensive with an easy change) - that way customers can either sail through quickly or make a clearly visible choice.

The one solution I need is:

  • refresh the checkout page on button select to update the shipping and total

Currently, the page will update on shipping drop-down select - but how to do that for radio buttons AND keep the button selection?

Here's my code so far, which fixes the label problem at least:

            <td colspan="4">
				<p>{$LANG.basket.shipping_select}:</p>
				<ul class="no-bullet center">
					{foreach from=$SHIPPING key=group item=methods}
						{foreach from=$methods item=method}
						<li>
							<input name="method" type="radio" value="{$method.value}" id="{$method.value}" {$method.selected|replace:'selected':'checked'}><label for="{$method.value}">{$method.display}</label>
						</li>
						{/foreach}
					{/foreach}
				</ul>
			</td>

I guess the other solution would be to put the select drop-down right in the price column, replacing the Shipping (Estimated) + cost .

The final solution has to be obvious and easy for the customer.

Link to comment
Share on other sites

"refresh on button select"

https://forums.cubecart.com/topic/47002-resolved-default-shipping-method/

In one of the posts, there is mention of a javascript function that can be edited to be more universal, instead of focusing on a select element. It is for a CC5 skin, so finding it in the CC6 skin's javascript may be a bit of a chore.

Link to comment
Share on other sites

Quote

In the file /js/common.js, near line 106, find:


$('select.update_form').change(function(){

Remove the word select.

For CubeCart v6.0.12 this seems to be in /js/common.js at line 109.

	$('select.update_form').change(function(){
		$('input.required').removeClass('required');
		$(this).parents('form').submit();
	});

But I wasn't able to get it the code change to work, so returned it to how it was.

I tried selecting the expensive radio button and then clicking the update basket button. It submitted/updated the form but the radio button defaulted to the cheapest option again.

I tried adding onChange='this.form.submit();' to the input tag for the radio buttons (because I couldn't get update_form to work) but it again defaulted to the cheapest option.

The drop-down select keeps its value on select/submit so I don't know what's going on. How do I make the radio option sticky when the form is updated?

I'm OK with the cheapest option being chosen by default in the first instance, but I want any change to update the form with new shipping and total values and for the chosen radio button to remain checked after update.

Link to comment
Share on other sites

In CC6, the only skin included is Foundation. The above is for, as mentioned, a CC5 skin.

The corresponding javascript file for Foundation is /skins/foundation/js/2.cubecart.js.

Near line 28:

    $(".autosubmit select").not('.nosubmit').change(function() {
        $(this).parents(".autosubmit").submit();
    });


Change this part:

$(".autosubmit select")

to be:

$(".autosubmit select, .autosubmit input[type='radio']")

The jQuery selector will now include a select tag inside something having an autosubmit class, as it did before, and also an input tag of type radio inside the autosubmit class.

Be sure to force your browser to reload the edited javascript file.

Link to comment
Share on other sites

With that change the form submits on radio, but the problem now is that the radio button value will not change. On further testing, it's not defaulting to the cheapest value but to the last selected value. Once there's a selection it won't allow it to change - it returns the first selection only.

Link to comment
Share on other sites

The stock template code in content.checkout.medium-up.php (and content.checkout.small.php), is:

               <select name="shipping">
                  <option value="">{$LANG.form.please_select}</option>
                  {foreach from=$SHIPPING key=group item=methods}
                  {if $HIDE_OPTION_GROUPS ne '1'}
                  <optgroup label="{$group}">{/if}
                     {foreach from=$methods item=method}
                     <option value="{$method.value}" {$method.selected}>{$method.display}</option>
                     {/foreach}
                     {if $HIDE_OPTION_GROUPS ne '1'}
                  </optgroup>
                  {/if}
                  {/foreach}
               </select>

Take note of the form element name. In this case, the select tag has the element name of "shipping".

Your radio button loop is:

Lines wrapped for clarity:

{foreach from=$SHIPPING key=group item=methods}
  {foreach from=$methods item=method}
  <li>
    <input name="method" type="radio" value="{$method.value}"
           id="{$method.value}" {$method.selected|replace:'selected':'checked'}>
    <label for="{$method.value}">{$method.display}</label>
  </li>
  {/foreach}
{/foreach}

The radio input element needs to have the same name that CubeCart is expecting ("shipping"). So, try changing:
<input name="method"
to
<input name="shipping"

 

Link to comment
Share on other sites

Grumble - still having other problems with the shipping select.  In content.checkout.small.php there is this at line 86:

<select name="shipping" class="field_small_only nomarg">

Well, on a small viewport in using my old version of Safari this doesn't work as a dropdown - it's just solid which means customers can't make a selection.

If I remove the class, then this interferes with content.checkout.medium-up.php and the dropdown won't accept any changes - maybe there's a conflict in the code with using the name "shipping" because one control is just hidden, not absent from the code.

My version of content.checkout.small.php is 100% Foundation - so I'm wondering if it affects medium-up then maybe it's causing some issue with the radio buttons. (Grasping at straws here)

Link to comment
Share on other sites

Thank you bsmither.

Radio buttons for shipping in content.checkout.medium-up.php are now working.  Here's a summary for anyone else interested.

In /skins/foundation/templates/content.checkout.medium-up.php

Find this:

            <td colspan="4">
               {$LANG.basket.shipping_select}:
               <select name="shipping">
                  <option value="">{$LANG.form.please_select}</option>
                  {foreach from=$SHIPPING key=group item=methods}
                  {if $HIDE_OPTION_GROUPS ne '1'}
                  <optgroup label="{$group}">{/if}
                     {foreach from=$methods item=method}
                     <option value="{$method.value}" {$method.selected}>{$method.display}</option>
                     {/foreach}
                     {if $HIDE_OPTION_GROUPS ne '1'}
                  </optgroup>
                  {/if}
                  {/foreach}
               </select>
            </td>

Replace with this:

            <td colspan="4">
              <p>{$LANG.basket.shipping_select}:</p>
                <ul class="no-bullet center">
                  {foreach from=$SHIPPING key=group item=methods}
                  {foreach from=$methods item=method}
                  <li>
                    <input name="shipping" type="radio" value="{$method.value}" id="{$method.value}" {$method.selected|replace:'selected':'checked'}><label for="{$method.value}">{$method.display}</label>
                  </li>
                  {/foreach}
                  {/foreach}
              	</ul>
	     </td>

And in /skins/foundation/js/2.cubecart.js

Find:

$(".autosubmit select").not('.nosubmit').change(function() {

Replace with:

$(".autosubmit select, .autosubmit input[type='radio']").not('.nosubmit').change(function() {

 

Still some tinkering to do, but I think that offering customers an immediately visible choice of shipping using a couple of radio buttons is much better than a select drop-down.

Thank you again for your help, bsmither :)

Link to comment
Share on other sites

In content.checkout.small.php, the elements with class "field_small_only" are disabled by a javascript function (2.cubecart.js near line 299) when the viewport is medium or wider.

Non-displayed form elements may still have their values submitted -- that depends on the browser.
https://www.w3.org/TR/html401/interact/forms.html#h-17.13.2

 

Link to comment
Share on other sites

  • 2 weeks later...

One thing though, about the radio buttons for postage auto-submitting - the radio buttons for payment methods also auto-submit on click.  Is it possible to stop that behaviour, perhaps by adding .nosubmit class, without breaking the form?

Like this?

<input name="gateway" type="radio" value="{$gateway.folder}" id="{$gateway.folder}" class="nosubmit" required {$gateway.checked} rel="gateway_error"><label for="{$gateway.folder}">{$gateway.description}</label>

 

Link to comment
Share on other sites

  • 10 months later...

I've noticed a couple of overseas orders slipping through on local rates lately. I'm thinking that if the customer is logged in that their country is recognised and they get the correct shipping, but if the customer is new and just filling out their details then the postage (already quoted at the local rate) may not be getting updated for their country.  Is there an extra check I can activate when the customer changes the country while they fill out their details?

Link to comment
Share on other sites

I want the postage estimates displayed because most of my customers are local.  However, I'm not sure why overseas customers have slipped through with local shipping rates.  Seems to be the last two (since 13 June), all the previous overseas sales seem to have the correct shipping.

My checkout has been modified for radio buttons - which is why I posted here (modifications are discussed in this thread).  The radio button code changes may have caused the shipping rates to not be updated as the customer completed their details, or it may happen on a vanilla Foundation store - I don't know.  I'm still using 6.0.12 (still waiting on some features before upgrading).

The radio button code has been in operation since Aug 2016, so there must be another fail point.

Edited by jasehead
Link to comment
Share on other sites

  • 4 months later...

Still getting instances of overseas customers being able to complete an order and pay only local delivery rates rather than airmail - for a recent order the price I paid to send the item was more than the total (goods+shipping) that the customer paid, so I felt like I sent them the goods for free and paid them a tip for my trouble.

I think the issue occurs when the customer is purchasing as a guest rather than being logged in.

Cubecart v6.0.12 Foundation - no upgrade until after Christmas sales period is over.

Link to comment
Share on other sites

  • 4 months later...

Is this still happening on the new version of Cubecart?

I have experienced this problem for years on my older version of Cubecart.

For us: it sometimes happens when a guest customer chooses a delivery option for a quote, which is then no longer available in the dropdown once they have entered their delivery address. e.g. "UK Courier delivery" for overseas customers or "Free delivery" (orders over £75) if a customer deletes something out of their basket after selecting this option.

I am about to upgrade to the latest version and assumed this had been fixed. I will file a bug report if not.

Link to comment
Share on other sites

Depending on the version you are using when you are experiencing this situation, after upgrading, you may now have a new option to suppress estimated shipping until CubeCart has a Delivery address.

Also, CubeCart has for the past several versions, notified the customer that "New Shipping Options have become available" whenever the delivery address changes.

So, look for these.

Link to comment
Share on other sites

  • 4 weeks later...

I'm testing 6.1.14 with the radio buttons for shipping (see thread), but there seems to be an issue with removing an item from the basket - if I click the delete icon the item doesn't delete, even though the page flashes from a refresh.  Manually refreshing the page or clicking Empty Basket doesn't work in a similar way, but the Update Basket button DOES work and then shows the updated basket with all changes.  I've tested the default Foundation skin and the problem persists, so I'm at a loss.

I did have one edit in /js/common.js at line 109 (from my post on August 3, 2016):
$('select.update_form').change(function()
was changed to
$('update_form').change(function()

Tested, but didn't solve the remove-item-in-basket problem.  Interesting that this old edit didn't seem to change anything in 6.0.12 over the past two years.

---

A workaround would be to fire off the Update Basket button or similar code when the Empty Basket button or a Delete/Remove item icon is clicked - any suggestions on how to do that?

---

This also seems to be an issue with my live store running 6.0.12 (clicking the delete icon doesn't appear to remove an item from the basket) - so this may be a pre-existing problem for me.  I tried the CubeCart DEMO store and couldn't reproduce the issue.

Edited by jasehead
Link to comment
Share on other sites

Please do the following:

In admin, Store Settings, Advanced tab, enable debugging and enter your IP address in the adjacent field (www.whatismyip.com).

View the Shopping Basket page with something in the shopping basket. The debug section below the regular contents will show a __basket => array with contents being an array of 32-character hashes. Take note of the first few characters of the first hash.

Scroll up to the Shopping Basket list and hover the mouse cursor over the delete icon of the first item. The browser should show the URL that this link points to. The link should have within it: /index.php?_a=basket&remove-item=hash_noted_earlier.

If that checks out, then the problem is not with the skin.

I will look to see where there may be a possible place in the code that might thwart removing items from the shopping basket.

Link to comment
Share on other sites

In the debug section, I see '_a' => basket in the sanitise section with no hash. Then, further down, there is '__basket' => 'contents' => and each item has its own hash. The items in the debug are listed in reverse order, but each hash matches the remove-item hash.

I was able to remove one or two items from a list of 12 before it stopped working - sometimes the last item in the list can be removed OK.

Tested with the user not logged in and then logged in - same result.

I did think that most of my edits (radio buttons in this thread) were done in my custom skin, and changing back to the vanilla Foundation skin still has the same issue.  Can you suggest any core files that would play a part in the shopping cart?  The items not working for me are the Empty Basket button and the remove-item icons.  Refreshing the page doesn't fix the basket but the Update Basket button does.

Edited by jasehead
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...