nathanbright

Member
  • Content count

    24
  • Joined

  • Last visited

Community Reputation

0 Neutral

1 Follower

Recent Profile Visitors

1,272 profile views
  1. 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. 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. 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. 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. 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