Jump to content

Radio buttons for shipping on checkout


jasehead

Recommended Posts

Code snippets:

  • Apply a discount code via a URL - class.user.register_user.inserted
  • Send registration confirmation email - class.cart.construct.pre
  • Makes sure random (featured) product to be shown is in stock - class.gui.display_random_product

NOTE: When I reviewed these, there was no PHP code visible (I recently upgraded the dev site from 6.0.12 to 6.1.14) so I have just now rebuilt each snippet. I found that clicking the delete icon on the old code snippet had similar problems to removing an item from the basket.  Deleting a snippet only worked if the page was fresh.

Plugins:

  • By Weight 1.1.0
  • Card Capture 1.0.5
  • Mailchimp 1.0.1
  • PayPal 1.0.4 (PayPal Standard Payment Gateway)
  • Preorder Goods 1.0.4
  • Print Order Form 1.0.1

Possible custom code edits having an effect:

/js/common.js - line 109: (see jasehead post 219517, August 3, 2016)
was
$('select.update_form').change(function(){
changed to
$('update_form').change(function(){
but also tested as original code and doesn't seem to make any difference anywhere

/skins/mycustomskin/2.cubecart.js - line 82: (see bsmither post 219518, August 3, 2016)
was
$(".autosubmit select").not('.nosubmit').change(function() {
changed to
$(".autosubmit select, .autosubmit input[type='radio']").not('.nosubmit').change(function()

 

Still confused that the Foundation skin with no edits has the same issue, and that the code snippets page in Admin had a similar problem with deleting items.

Enable Debugging seemed to cause a too many redirects error, so had to disable again.

Link to comment
Share on other sites

I'm finding the same issue in our live store running 6.0.12 - I'm going to wind back to 6.0.11 to see if there is any difference (that was before the radio buttons mod).

I don't remember deleting items from the basket being any problem.  Some customers did they they had problems deleting items but whenever we tested it worked fine for us, although we did notice some rare orders come in that had one or two items with no description and a $0.00 value.

One other thought - we have just moved web hosts, so I'm wondering if there could be any issue with that.  We had do dumb down to PHP 5.6 for one of our CubeCart plugins to work.  Would there be anything in the server environment that could be causing this issue?

Link to comment
Share on other sites

Looking at CCv6.1.14 /classes/cart.class.php around line 1019, I see that the remove function is supposed to (if it works) finish by calling the update function around line 1066.  I tried moving...

return $this->update();

...to outside of the IF clause so it would fire regardless - no change. Also tried commenting out the IF clause and closing bracket so the code would run unconditionally - still nothing.

To test this I used CubeCart Admin to empty the cache, and also emptied browser cache, deleted history and reloaded page from origin - so it should have been fresh.

WORKAROUND

Clicking the remove-item icon does remove the item (and the Empty Basket button too), but nothing appears to change and the basket is only refreshed properly by the Update Basket button.  Can you suggest a way to make the Update Basket button effect work after any code for remove-item or empty basket has been executed?

Edited by jasehead
Link to comment
Share on other sites

After reverting to earlier backups, removing all custom edits, turning off Expires Caching in htaccess, trying a vanilla install of 6.1.14 without plugins and working through Maintenance > Database to fix all indexes I'm still lost.  I don't understand why remove-item and Empty Basket won't work properly.  I thought that the basket wasn't working as a result of the radio buttons mod above, but it seems not.  I don't understand why remove-item might work once for one item out of six, but not for any others.  I don't understand why the Update Basket button updates the cart and refreshes the page but the Empty Basket button doesn't.

Link to comment
Share on other sites

Turning off "Expires Caching"?

Making the assumption that your hosting provider has implemented some sort of server-level webserver-based optimization utility or man-in-the-middle caching appliance, can you discern if any of that is in play and have it completely disabled?

Link to comment
Share on other sites

I had set some ExpiresByType set in .htaccess for some items set to one month - I've disabled all of that.  Still waiting on response from hosting provider.  Server is running PHP 5.6.35, 10.2.14-MariaDB, LiteSpeed.  Whatever the issue for 6.1.14, it's also the same problem for my live 6.0.12 cart.

Wouldn't be a PHP extension?

The remove-item icons and Empty Cart button are coded as links where the Update Basket is a submit button and the radio buttons also submit the page to recalculate postage.  Can I change the remove-item and Empty Cart links to be submit buttons instead, or in some other way get a click on these to submit the page?

Edited by jasehead
Link to comment
Share on other sites

UPDATE - my server does have lscache (LiteSpeed Cache) built in. 

I though CubeCart was meant to work OK on LiteSpeed (!)

I'll disable lscashe from .htaccess by adding: 

CacheDisable public /
CacheDisable private /

AND WOULD YOU BELIEVE THAT IT FIXED THE PROBLEM?!?!

Remove-item and Empty Basket both working.

Edited by jasehead
Link to comment
Share on other sites

Good to hear!

Maybe works with LiteSpeed as a web server, but maybe not so much with its aggressive (and temperamental?) caching?

"Can I change the remove-item and Empty Cart links to be submit buttons instead, or in some other way get a click on these to submit the page?"

I would think so, but there would be a problem with that.

CubeCart expects the remove-item key (and empty-basket key) to be in the querystring $_GET array. A submit button generally puts things in a POST payload. The core code could be changed to deal with that, however. (A submit button can be programmed to submit form elements as a querystring, but then we are back to square one with the querystring being mishandled by the man-in-the-middle cache utility.)

A work-around would be to indicate to the customer that to remove items, set their quantities to be zero. Then Update the basket. Remove the delete icon and Empty Basket button from the skin code.

Link to comment
Share on other sites

Before the LScache problem was fixed with CacheDisable in htaccess, clicking on a remove-item icon or the Empty Basket button did prime something because clicking the Update Button then put that into effect.  I could click to remove item #2 and then click the Update Basket button to "make it so".

Workaround no longer required but, programatically, rather than changing the behaviour of remove-item or empty-basket the trick would be to then fire the Update Basket button.

I agree that disabling the non-working elements would be the quickest solution.

Link to comment
Share on other sites

I am reminded that you did say that the page did refresh. But the page that was returned had the same data. To me, that is indicative of an over-agressive cache of a certain kind. CubeCart received the querystring and processed it, but the cache sent back an existing page.

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...