nathanbright

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

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)

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?

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?

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

Aha, yes, we run module not FastCGI Thanks again for your help

Agreed about wanting to know why increase memory allowance worked Correct me if I am wrong, but our error_log value is NULL which means that Apache handles the errors and puts them either in the apache vhost error log (if it knows at the time of the error) or the "root" apache error_log Certainly we have a few "PHP Warning:" lines already in the logs suggesting this Neither error log had any report of an out-of-memory issue (just the segmentation fault I mention above) - we only know that increasing memory solved the problem All said in the spirit of offering more info if someone investigates this further (I shall be upgrading PHP this week, I'll report back to say if that allows the status change with the lower amount of memory)

Right, I see what you are doing there, getting logging turned on. Completely understand, but already on (going to the Apache log), reporting level 65527 (just about everything) HOWEVER memory_limit was at 128M and increasing to 256M SOLVED THE PROBLEM So, cool, thanks again Hope this helps others

I upgrade from 6.0.8 to 6.0.10 last Thursday All orders since that date cannot have their status changed by Admin What happens is a "blank screen": Chrome reports 'No data received'. Firefox reports 'The connection was reset' The apache error log shows nothing. Hmm, and I just looked at the access log and that is showing nothing too, no request gets sent to the server The original status change from Pending to Processing that happens when a payment succeeds *is* happening. We have checked changing "Pending" to any other status, and "Processing" to "Complete" and all result in the behaviour above PHP version 5.3.3 Apache 2.2.16 Ah, apache "root" error log is reporting "child pid XXX exit signal Segmentation fault" which Google tells me is likely to be some sort of internal PHP error - any chance anyone in the know about what has changed in the order status change code that might be relevant to this?

Ha, completely on the money again, thanks In case it helps others Yes, JPEG enabled, yes to correct header and footer bytes in the image file, reluctant to add a third party metadata stripper Problem solved by using the work-around in that bug report https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=798866 So gd.class.php line 101 becomes $this->_gdImageSource = imagecreatefromstring(file_get_contents($file)); NOTE: this is because we are still on Debian LTS on that server, so in theory this problem will go away if / when either: (a) the bug above gets fixed (assuming the fix applies to JPG as well as PNG); or (b) we upgrade the server to a modern PHP NOTE 2: Upgrading Cubecart might remove this fix. If so it will need re-applying Thanks again

Strange one. I upgraded a shop to version 6 last year (I think it was from v4) Cached images and thumbnails all working I failed to test creating a new product (!) The client has now just created a few new products but the images are not appearing properly. Uploading an image using the media upload tab in the product manager results in the source image uploading to /images/source/. I've re-downloaded it over ftp and checked it is byte for byte the same as the orginal But no images (the various different size versions) are getting created in the /images/cache/ folder. So the new products have no images showing on the front end I tried clearing the image cache to see if it was some issue with the format of the new images but then had to restore from backup as all product images were gone The error log is reporting PHP Warning: imagecreatefromjpeg(): bad type specifier while parsing parameters /classes/gd.class.php on line 101 GD support is installed (version 2). PHP version 5.3.3 Folder permissions are 755 and correct owner and group Given no-one else reporting anything like this, I assume there's something specific about our setup but at a loss Nathan

Yep, that makes sense Are there any tools, possibly as part of github, that can be used to see differences between releases of individual files? So for instance to see the changes (if any) in <Foundation skin>/content.category.php between CC version 6.0.1 and 6.0.2

Got it. Typically enough, staring me in the face I doubt this will help anyone but for the sake of completeness. I had this <input type="text" name="add[{$product.product_id}][quantity]" value="1" class="quantity text-center"> which should have been this <input type="text" name="quantity" value="1" class="quantity text-center"> I.e. it was being serialised fine, just being given the wrong name Thanks for the help, good learning going on here

Aha, that explains my mystification, serialised Thanks. I'll check again given this new info

Hi Al et al Apologies for the "radio silence", I tried bsmithers solution, did not solve my issue, then went on holiday You are quite right Al, I took a copy of Foundation back in late March (2015). Unfortunately for me there have been significant changes since, so "diff"ing gives me a "snow" of changes. So much so I feel I am unable to reverse them all in (as well as not being able to determine which is the solution to my issue) It feels like that missing ID input field is relevant I appreciate this is effectively an unsupported branch of the Foundation code, but would appreciate if someone could point me at the javascript that reads the quantity field during the add-to-cart action