Jump to content

nathanbright

Member
  • Content Count

    24
  • Joined

  • Last visited

Community Reputation

0 Neutral

1 Follower

Recent Profile Visitors

1,477 profile views
  1. nathanbright

    Language files revert to default when logged in

    Agreed, those are interesting questions and relevant to on-going CC development But to be honest, my concern is working out how the change from en-US to en-GB in customer records arose? I assume the code is the function createUser() classes/user.class.php where the code sets the user language thus $data['language'] = $GLOBALS['language']->current(); Ah, yes, that line is not present in 6.1.7, new in 6.1.8, so the DB table field default en-US was being set Ok, now I am satisfied I understand the issue, I can readily fix up the DB Thanks again for your help
  2. nathanbright

    Language files revert to default when logged in

    Right, a bit more info If I log in as a user registered last year, whose language is en-US, then the default text is displayed Logging in as a newly registered user, whose language is set as en-GB, things appear to work correctly, using the language overrides SO It appears that before June 6th users were being registered with en-US and it was using the (en-GB) language override when they logged in Since June 6th new registrations are being assigned language en-GB and are also using the en-GB language override The problem only arises when a prior-to-June-6th user logs in at which point they are seen as "normal" and do not get shown the language overrides Obvious solution steps include: (1) change all existing _customer language values from en-US to en-GB; (2) set the default on the _customer language field to en-GB (though I think this is what the new code is now doing, asserting this value rather than defaulting) My only question (assuming the above is correct) is "is there any way a new customer can get registered with any language other than en-GB?" (We don't have any other language enabled anywhere I know of)
  3. nathanbright

    Language files revert to default when logged in

    I should have said, doh Default language (Store settings): English (UK) and fwiw that is the only language in the drop-down Admin->Languages has two entries. The master entry is read=only, nothing to selsect / change. The second is seclected Master Language File (definitions.xml) (tick) English (UK) So, yes, the only enabled language is the same as the default language (English(UK)) Checking my debug session variables I see that there are both en-GB and en-US in there '__client' => 'useragent' => Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.113 Safari/537.36 'session_start' => 1506167490 'session_last' => 1506167513 'currency' => GBP 'admin_id' => 1 'language' => en-GB 'user_language' => en-US I wonder where it is getting en-US for user_language Thanks for the thought Keat. I expect we'll get to the point of doing something like that. But first we need to understand why this is happening, get to the cause as it were I have this all on a staging server that I can readily try things out on. I am tempted to try deleting all the _lang entries and see if they get re-created with the next order But before that I'd appreciate any further insights AHA - re-reading your first post bsmither (and thanks for the help) I just checked the default on the language field in the _customer table, it's en-US Could it be that a recent code change is now paying attention to that, triggering the DB language install?
  4. nathanbright

    Language files revert to default when logged in

    Yep, that's exactly what has happened. The _lang_strings table has 1669 entries, all en-GB The _customer table has en-US for all registrations until 6th June, after which all are en-GB That coincides exactly with the date we upgraded to 6.1.8 So, any suggestions what we do about it please?
  5. nathanbright

    Http code 408

    Whilst investigating a checkout issue, I have found a surprisingly high number of 408 response codes in our access log 408 means an http request was started by a client but nothing else arrived before the server decided to give up waiting (configurable in Apache 2.4 - KeepAliveTimeout = 5 (default) in our case). The server log entry has no referrer, request address (url) or agent. Nothing came in I am asking here because our CC website is the only one with any 408's (of half a dozen or so busy sites that I check the logs of) I'd appreciate it if people could let me know if they see this too. If not, I will assume we've some sort of issue with our skin (something to do with session management maybe?) which may in turn lead to clues about why a few customers have trouble entering a value for county during checkout
×