Hi.

This one is going to be hard to describe, so, please, just bear with me.

I've been trying to diagnose this for a few weeks, and due to both time constrains and my ignorance about ubercart I have been unable to find the exact problem. I have found a few things, though, and I hope someone here can help me narrow this down a bit.

I am using latest drupal 7 and latest ubercart 7-3, I am using flat rates only, subject to a few conditions that I will explain further below; I also have four payment methods, the and the only relevant one to the conversation is COD (cash on delivery), because I also defined a rule to increase the shipping quotes when choosing this one.

So, the rules are:

When total amount is < 40 AND payment IS NOT COD, then apply flat rate 1
When total amount is >= 40 AND payment IS NOT COD, then apply flat rate 2
When payment IS COD then apply flat rate 3

So far so good. We all know that the checkout page will only update the shipping quotes automatically when setting the zip code, AND NOT when selecting the shipping quotes, but my actual problem is not that (that's for another year).

My problem is as follows, and, please, forgive me for the long step-by-step, but this needs some context...

Example 1

I go to the checkout page. The payment panel (and all the rest of them) appear translated to Spanish, which is correct for my setup. I fill in all the details and when selecting the zip code it does its ajax thing and the panels reload. Most panels are correct as they were before but the payment methods panel appears in a perfect English, as if something got interrupted at some point.

I click the button to continue to the review screen. The page reloads and I am in the checkout page again (but at the top of it). The payment method panel this time is correctly translated again, I click the damn button again, this time it works.

Example 2

I go to the checkout page. The payment panel (and all the rest of them) appear translated to Spanish, which is correct for my setup. I fill in all the details and when selecting the zip code it does its ajax thing and the panels reload. Most panels are correct as they were before but the payment methods panel appears in a perfect English, as if something got interrupted at some point.

I click the button to continue to the review screen. The page reloads and I am in the checkout page again (but at the top of it). The payment method panel this time is correctly translated again. I then select another payment method, I click the damn button again, and then I am back at the top of the same checkout page.

I click the continue button a third time, and then I can proceed.

-------

So, for what it seems, when the payment method panel is changed either directly or via ajax, the checkout page enters an inconsistent state and from that point, I have to click, wait for it to reload, then click again so that I can fulfill the order.

I can't imagine how many orders I've lost due to this thing, but I am out of ideas on how to debug this.

I guess this is something odd, but I can't see any related js error in the browser console, and the drupal logs are not of much help either. So I am looking for any idea you can provide, more than a straight solutions.

I've done an amount of shops in ubercart before and I don't remember facing this same issue before.

Thank you for any help you can provide.

Comments

i92guboj created an issue. See original summary.

i92guboj’s picture

i92guboj commented

And yes, it happens in bartik as well. And no, pressing calculate shipping cost before submitting doesn't help either.

tr’s picture

tr commented
Priority: Major » Normal
Status: Needs review » Active

Needs Review status is for where there's a patch ...

The language issue is probably a bug - I don't think the Ajax has been extensively tested on a multi-language site. And since there's so many ways to set up language support, I need some details about how your site is set up so I can try to reproduce the error.

The other issue may just be your configuration. Enable uc_ajax_admin and go to the configuration page for that module and review the default settings - there may be some changes you can make here to avoid the problem.

i92guboj’s picture

i92guboj commented

Sorry, should have known better. I was thinking in something else...

The site is not multilingual, user-wise, but has some i18 modules, mostly to be able to translate the untranslated strings in the UI. As you said that, something crossed my mind, so I went, tested a couple things and reviewed the internationalization modules that I've enabled.

Soon enough I realised that the problem only affect users that are logged in, and, out of mere intuition I disabled the "Administration language" module.

Problem gone. I have yet to test thoroughly, of course, but it seems "fixed".

I only enabled that to keep the admin panels in English so I could easily report bugs and follow manuals, and it has been giving me a good headache for many months, since. Silly bug.

So, if you are looking for a way to reproduce this, I'd say you need to install Administrative language (right now I have 7.x-1.0-beta4+0-dev), and make sure you have the payments option panel enabled. I don't know if you need to define different flat rates to hit the bug or not. I tried disabling all but one and the bug continued to appear so I guess it's not relevant, but the rules where still there even if not enabled.

Then, use a different language for the frontend (I use Spanish) and the admin panels (English).

Maybe the problem is that the payment methods panel is mixing the admin-way to print options with the user-way to do it, because one of the options always translated correctly when the rest of them did not. I had not noticed that before, but that's it.

I thank you for the pointer which made me found a way around this. I also want to thank you for the ajax admin thing. Had no idea about it and it is indeed quite useful. Using it I could delete all the useless rules and just keep the one for the zip code. I also added one to update the payment method panel when changing the... payment method panel. With that, the panels self-updates solving my other problem.

The one thing that still bothered me is that the panel with the calculate button still needs to be present for the shipping costs to be added, but I can hide that with css.

Going back to the issue at hand, the only thing I've lost is the ability to use English in the admin panels, not a big deal and I can still enable that for me when needed (I'll have to check that simply having the module enabled doesn't interfere with the users which are not using different languages for the frontend and the backend).

Thanks!

tr’s picture

tr commented
Status: Active » Closed (works as designed)

So if I understand correctly, you were able to solve this with uc_ajax_admin. That's good - that's what it was designed to do. Since there's a possibility for circular dependencies in our Ajax (payment method dependent on shipping, shipping method dependent upon payment, etc.), we need uc_ajax_admin in order to provide some of this capability you're using.

Maybe the problem is that the payment methods panel is mixing the admin-way to print options with the user-way to do it, because one of the options always translated correctly when the rest of them did not. I had not noticed that before, but that's it.

I'm not sure what this means, but If you still have a problem with translations please open a new issue with some specific details so we can work on this without all the extra unrelated information in this issue. Thanks.