nathanbright

Member
  • Content count

    21
  • Joined

  • Last visited

Community Reputation

0 Neutral

About nathanbright

Recent Profile Visitors

897 profile views
  1. 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?
  2. 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
  3. [Resolved] Can't change order status at all

    Aha, yes, we run module not FastCGI Thanks again for your help
  4. [Resolved] Can't change order status at all

    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)
  5. [Resolved] Can't change order status at all

    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
  6. 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?
  7. [Resolved]Cached images not getting created

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