• Content count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About nathanbright

Recent Profile Visitors

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

    Aha, yes, we run module not FastCGI Thanks again for your help
  3. [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)
  4. [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
  5. 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?
  6. [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 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
  7. 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
  8. Add to cart from category page, more than one item

    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
  9. Add to cart from category page, more than one item

    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
  10. Add to cart from category page, more than one item

    Aha, that explains my mystification, serialised Thanks. I'll check again given this new info
  11. Add to cart from category page, more than one item

    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
  12. My version of the Foundation skin (CC6) ignores the count of products to add to the cart when doing so from the category page, in list mode (but it works if the page is in grid mode) This works in the Foundation skin so I suspect there's been a fix since I copied it My "diff juju" is not working, I cannot figure out where the item count is being read. Can anyone point me in the right direction please? I expect it's somewhere in either the 2.cubecart.js or perhaps an attribute in the css / html. But I can't see it for looking
  13. Product display changes from list to grid on re-size

    Brilliant, thanks, exactly what I needed, really appreciated
  14. On CC6 using the Foundation skin On a Windows browser, desktop size screen, I have my product category page set to "list" display (i.e. I have clicked on the list icon at top right of the list of products) I then reduce the width of the browser window to simulate seeing the page on a mobile. Then click on the home icon whilst at this minimal screen size, then get back to the product category page by selecting it from the Shop By Category drop-down Then re-size the page back up to desktop size, the display is now in grid layout not list This is a problem for us (besides being unexpected behaviour) as in our skin, based on Foundation, I have removed the layout icons, so we can't get back to the desired list layout I note that a cookie has been set called product_view, with value "grid" Can anyone suggest a way I can get back to the list layout in these cases? Do we think that the core code should not do this in the first place?