nathanbright
-
Posts
24 -
Joined
-
Last visited
Posts posted by nathanbright
-
-
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-USI 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
-
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
-
Brilliant, thanks, exactly what I needed, really appreciated
-
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?
-
Thanks both for the positive feedback
Collaboration - love it
(and thanks for the BeyondCompare pointer, going to look at that more closely)
-
We could extract the country name from the $COUNTRIES associative array but the smarty code is heavy going
I suspect the 'country' attribute was intended for this purpose but as Brian (?) says, safer to create the new attribute
Also (not checked yet) the same change probably needs applying to the delivery address
Github issue #693 raised
I am relatively new to Cubecart so apologies if that was inappropriate
-
Thanks for this solution on exactly the issue I have
BUT
Isn't /classes/cubecart.class.php a pretty fundamental core code file that is very likely to be overwritten by future security updates?
Nathan
-
Thanks for confirming I've not overlooked something
Ian makes good points, especially re SEO
As I say, I've coded the skin to show absolute prices. Ian, do you find you have to edit "core code" to implement this for the receipts / invoices? Guess I'll have another look at the code to see if I can head off that string concatonation
Nathan
-
Template based on original from recent upgraded CC4
We have some standard (I would have thought) product size options. In the admin of the product options we appear to be required to enter the price and weight as the difference from the "base" product. So for instance, a base product Aromatherapy Oil 10ml, £5.30, then a larger one 25ml, costing £9.50, we have to enter it's price difference of £4.20
The customer facing product page options drop-down then displays this as "25ml (+ £4.20)" rather than telling the customer the actual price - strange. I've re-coded the product page template to calculate and display the whole price
But the customer facing invoices and receipts have this differential pricing string in them, inserted in the core code (I assume, can't find where it is done in template code if it is). I.e. I can see by using Smarty {debug} on the receipt page that the product options string has been coed by concatenating the title and price difference strings again. To convert to actual price I would have to do string manipulation
Is this expected behaviour? I feel like I've overlook something fundamental as I can't recall seeing this displaying of the difference in price on other websites?
I see that the demo site only has one product option, "Installation service + £50", where this makes sense
And now I come to look, I cannot see other sites using this mechanism, they appear to make different sizes as different products
-
I'm having trouble making "Phone" NOT a required field in the user profile when using the Foundation skin (CCV6.0.2)
Simply removing the "required" class parameter from the <input> tag does not achieve it. It appears to be also hard coded into the javascript validation functions in /js/3.cubecart.validate.js
And simply removing that javascript file (temporarily to test), left me with a PHP validation failure
Have I misunderstood how required fields are meant to be handled in V6?
Language files revert to default when logged in
in Technical Help
Posted
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