[quote name=‘tbirnseth’]I just don’t see that in the code. Localization is only kept in a cookie What’s your URL, I’ll try to access it (since I’ve never been there before) and tell you what I see as a default. Or send me an email at XXtonyb@XXez-ms.comXX without the X’s and we’ll synchronize the test. I.e. you can set it to something other than Austrailia and then I’ll go to your site and tell you if the default is Austrailia. My bet is that it will be.[/QUOTE]
Thanks for the reply … deep breath
Well there must be some fault that causes this because;
1 - Australian customers are complaining that they cannot see all the shop products and then when I have checked with them the default localization has switched to International without any changes on their part.
2 - I visit my store front one day and its defaults to Australia and the next day (after a OS visitor has manually selected International) the shop defaults to international for me without any changes on my part.
Today its been all over the place for me I have disabled and re-enabled the International localizations several times trying to get it to reset the default to the default setting. The actual default in store front has swung between all three localizations regardless of the fact that I have manually selected “Australia” and Australia has remained the default in the admin at all times.
I can say unequivocally it is not a local cookie as I have not manually selected a international localization, I have nuked my browser cache dozens of times today, I have tested the shop front on three separate PC’s locally and I have asked two Australian customers to check their end (same result when checked at the same time).
Now after resetting the store front no less than 20 times, disabling and re-enabling International localizations several times, clearing the shop cache, adding products to cart in Australian testing accounts and asking two Australian customers to manually select Australia in the shop front FINALLY this damn thing is defaulting to Australia when I or a customer visits the store front. Until the next time no doubt!
[url]Best Cosmetic Tattoo & Permanent Makeup Supplies in Australia
Couple this with the ongoing problems with Tag links and I am not a happy camper today.
[url]http://forum.cs-cart.com/showthread.php?t=21483[/url]
Hate toask, but have you asked the helpdesk? Many times issues are siimply silently resolved (to most of us) and some benign entry shows up in the changelog that would take a crystal ball to determine that it fixed a problem…
It’s that merry time of year! Chin up, you have customers visiting your site!
PS: my localization was Austraila when I just clicked your link!
[quote name=‘tbirnseth’]Hate toask, but have you asked the helpdesk? Many times issues are siimply silently resolved (to most of us) and some benign entry shows up in the changelog that would take a crystal ball to determine that it fixed a problem…
It’s that merry time of year! Chin up, you have customers visiting your site!
PS: my localization was Austraila when I just clicked your link![/QUOTE]
Yes I have raised a ticket and waiting for a response.
Interesting that my shop defaults to Australia for you (in US) as by your previous evaluation of the back end it should recognise your location as not Australia and presumably load “International” as the localization because that option has the country US assigned.
The issue mentioned seems to arise after a OS visitor manually changes to a different localization and adds some products to cart etc then often it will create a new phantom default.
Oh well at least my tag links are showing images now, as expect it was a minor code error issue (false should have been true) in tags.php
I suspect that localization needs a thorough examination to get it working sensibly i.e. auto detecting visitors IP and loading correct localization option, if as you previously suggested the code is there to make that happen then it obviously just needs to be worked through to debug it.
Well I raised a ticket on this issue and here are the replies that I received;
[COLOR=“Sienna”]When a customer registers or signs in, the system identifies whether the country specified in his/her profile fits any localization.The system sets the default localization automatically if there is no localization for the customer’s country.
If the system can identify the customer’s country (by IP, cookies, etc.) and this country is specified in one of localizations, it sets this localization for the customer automatically.[/COLOR]
&
[COLOR=“sienna”]When a customer visits the store for the first time, the system will identify the localization in the way I have mentioned in my previous message. Then the localization is written in the permanent cookie file. So if the customer changes the localization in the store, the change will be saved in the cookie file. That is why if he visits your store next time, he will see not the last chosen localization, not default.
NOTE: By default the cookie file are kept for one week since the last visit of the store and then it is deleted. Also you can change its value in the “config.php” file of the root directory of your CS-Cart installation:[/COLOR]
[COLOR=“DarkGreen”]// Live time for permanent cookies (currency, language, etc…)
define(‘COOKIE_ALIVE_TIME’, SECONDS_IN_DAY * 7); // one week[/COLOR]
So according to support localization should automatically detect and load the correct localization for their country based on their IP or country within their profile.
&
A cookie is created when a localization is manually selected that lasts 1 week that should automatically load the last setting selected.
The problem is that my experience of the localization feature is that none of that works properly and judging by the issues raised in the forum others are saying the same thing.
- Locallization is not loading automatically on login based on IP or country in profile.
- Localization is not consistently automatically loading the last selected option.
- Localization seems to have a brain fart sometimes when a customer manually selects an option the shop then loads that option by default for all subsequent visitors ignoring the default set in admin panel and ignoring their country and IP.
IF there is a someone out there who is actually using localization in an active shop and has experienced it working the way that support say it is supposed to work I would love to hear about it.
Having ongoing issues with this faulty feature.
I have three straightforward localization settings and yet the cart continues to spasmodically develop a fault where it loads the wrong localization by default which can only be rectified by disabling the localization which is incorrectly loading for period of time until the shop inexplicably resets, sometimes after an hour or two sometimes a couple of days.
I have gone back and forth with support and here on the forums but nobody seems to have the answer for this fault. It as nothing to do with cookies etc its simple case of the localization feature being buggy and not working properly.
As nobody has answered here I can only assume that nobody else has managed to get the feature working either.
I have not observed a bug report in the BugTracker. Have you posted one? That seems to be the thread where developers actually look at things.
[quote name=‘tbirnseth’]I have not observed a bug report in the BugTracker. Have you posted one? That seems to be the thread where developers actually look at things.[/QUOTE]
I opened a ticket with support in the hope of getting the issue resolved sooner rather than later on a product update, hence the replies that I posted. But it takes a while to present your case before an engineer is tasked it seems.
Like yourself they seemed to assume this was a persistent cookie, but for a cookie to cause an option to load that was not the default nor the correct for country then you would actually have to manually select it after which supposedly the last option manually selected is supposed to load. And as mentioned to them I cant see how a cookie on a customers PC in USA affects a customers default localization in Australia nor my own PC when I know I have not manually selected anything in store front.
Also contrary to what I have been advised about how the cookie is supposed to work with last option selected loading on next visit I find in practice that does not happen. International loads as default incorrectly so I manually select 'Australia" , shut-down the browser and “International” loads incorrectly again.
So on a sporadic basis it is ignoring;
- Default localization setting in admin panel
- IP identifying country for correct localization
- Browser Language / Country for correct localization
- User account country for billing and shipping for correct localization
- Last option selected manually
Connecting via different PC’s different ISP’s and via different countries via proxies yields the same error, not sure how much more is required to convince that bug exists. But to be honest I have not seen anything in the forums that would convince me that a customer has an active store operating that actually has localization working and automatically selecting (correctly) the right localization based on the assigned countries.
It seems to me that this feature has not been developed properly
I have had to disable one of my 3 localizations for most of the day today simply because it keeps load as the default “International” when “Australia” should be loading. Even when logging into a user account at store front it still is not detecting the billing and shipping country “Australia” and loading the Australia localization, not even sure if that ever works as claimed on the tin.
Disabling the localization option that is loading incorrectly seems to be the only way to deal with it.
Helpdesk is a far cry from the developers. Their job is to insulate the development team, not get answers from them. So I would suggest that you submit a bug in the Bug Tracker with a concise description of the problem and how to reproduce it.
I have had the following reply from support;
In order to solve the problem, I replaced the code:
[COLOR=“DarkGreen”]$_ip = fn_get_ip(true);
$_country = fn_get_country_by_ip($_ip[‘host’]);
$_lngs = db_get_hash_single_array(“SELECT lang_code, 1 as ‘l’ FROM ?:languages WHERE status = ‘A’”, array(‘lang_code’, ‘l’));
$_language = fn_get_browser_language($_lngs);
$cart_localization = db_get_field(“SELECT localization_id, COUNT(localization_id) as c FROM ?:localization_elements WHERE (element = ?s AND element_type = ‘C’) OR (element = ?s AND element_type = ‘L’) GROUP BY localization_id ORDER BY c DESC LIMIT 1”, $_country, $_language);
if (empty($cart_localization) || empty($locs[$cart_localization])) {
$cart_localization = db_get_field(“SELECT localization_id FROM ?:localizations WHERE status = ‘A’ AND is_default = ‘Y’”);
}[/COLOR]
with this one:
[COLOR=“darkgreen”]// [mink]
/* $_ip = fn_get_ip(true);
$_country = fn_get_country_by_ip($_ip[‘host’]);
$_lngs = db_get_hash_single_array(“SELECT lang_code, 1 as ‘l’ FROM ?:languages WHERE status = ‘A’”, array(‘lang_code’, ‘l’));
$_language = fn_get_browser_language($_lngs);
$cart_localization = db_get_field(“SELECT localization_id, COUNT(localization_id) as c FROM ?:localization_elements WHERE (element = ?s AND element_type = ‘C’) OR (element = ?s AND element_type = ‘L’) GROUP BY localization_id ORDER BY c DESC LIMIT 1”, $_country, $_language);
if (empty($cart_localization) || empty($locs[$cart_localization])) {
$cart_localization = db_get_field(“SELECT localization_id FROM ?:localizations WHERE status = ‘A’ AND is_default = ‘Y’”);
} */
$cart_localuzation = ‘9’; // Select the “Australia” localization for new customers.
// [/mink][/COLOR]
Which I think is disabling the IP country and account country influences on localization and if that is the case also reduces the functionality of the feature. However it has not fixed the problem because the wrong default localization is still loading. It also looks like a error on the final line “localuzation”.
Edit:
After editing the spelling error made by helpdesk “localuzation” to “localization” now “Australia” appears to be loading as the default selection however the last selected localization does not load and with my very limited knowledge I cannot see with the above disabled code anywhere that the cart was ever actually checking for existing cookies for the last selected localization?
If you look at the code, they simply commented out all the logic and hardcoded it to “9” which must be the localization key for Austrailia.
[quote name=‘tbirnseth’]If you look at the code, they simply commented out all the logic and hardcoded it to “9” which must be the localization key for Austrailia.[/QUOTE]
Yes that is what I assumed had been suggested as “the fix” which highlights my earlier comments that in its current form localization does not work as it states on the tin. I can however confirm that there is some degree of checking of an active session cookie for the manual selection of the localization, after a lot of checking yesterday I did find that the selection from the last session does (sometimes) load if there is a retained cookie in the browser cache. So I assume that part of the code lives somewhere else.
Hopefully they can find a way to get this working properly
Still strongly suggest you submit to the BugTracker versus Helpdesk if you want someone to actually look at the problem.
OK so the previous edits have been reverted and it appears that they may have isolated the bug to “geoip.php” file in the “lib/geoip” directory of CS-Cart installation. So just as I thought there is a bug in the standard CS-Cart installation that prevents it from operating properly.
For those interested in the changes that have been made I have uploaded my geoip.php file with added the extension .txt otherwise it could not be uploaded.
NB.
I have not extensively tested this yet but it appears to be correctly loading the assigned default Localization and on testing via some web proxies it has correctly loaded the assigned Localization based on visiting IP country for some but not all proxies that were tested and those that were not identified defaulted to the assigned default localization. I assume that the IP table being used cannot identify every site visitor and therefore defaults when it cannot identify the visiting IP country.
At this stage I do not know if it is correctly identifying the country of an account on login and automatically loading the assigned Locaization but if not the changes made are at least a step in the right direction for getting Localization to actually work.
Take note of my current cart version 2.1.2 and make sure you back up before making any changes just in case!
They use a static database of geoip info. If it’s been changed since they started, then the updates would not be reflected. Not sure why the don’t use a dynamic site so they would get real-time info… It could be cached in the SESSION so only one lookup would be required.
Ok. There hasn't been any update for this thread for a while. Anybody ever tried this method please share your experience if this file fixed the problem for any other people and also, on most current 2.2.4 version?
By the way, any people came up with or knew someone who created any add-on or mod available for sale, for this topic?
Thanks!
[quote name='CosmeticTattooist' timestamp='1294959571' post='100452']
OK so the previous edits have been reverted and it appears that they may have isolated the bug to “geoip.php” file in the “lib/geoip” directory of CS-Cart installation. So just as I thought there is a bug in the standard CS-Cart installation that prevents it from operating properly.
For those interested in the changes that have been made I have uploaded my geoip.php file with added the extension .txt otherwise it could not be uploaded.
NB.
I have not extensively tested this yet but it appears to be correctly loading the assigned default Localization and on testing via some web proxies it has correctly loaded the assigned Localization based on visiting IP country for some but not all proxies that were tested and those that were not identified defaulted to the assigned default localization. I assume that the IP table being used cannot identify every site visitor and therefore defaults when it cannot identify the visiting IP country.
At this stage I do not know if it is correctly identifying the country of an account on login and automatically loading the assigned Locaization but if not the changes made are at least a step in the right direction for getting Localization to actually work.
Take note of my current cart version 2.1.2 and make sure you back up before making any changes just in case!
[/quote]
[quote name='chriswongus' timestamp='1332192427' post='133438']
Ok. There hasn't been any update for this thread for a while. Anybody ever tried this method please share your experience if this file fixed the problem for any other people and also, on most current 2.2.4 version?
By the way, any people came up with or knew someone who created any add-on or mod available for sale, for this topic?
Thanks!
[/quote]
I have been running my site with this modification since the last post and localization seems to get it right most of the time.
Some important points make sure that you do not double up countries and states in the different Locations & Localizations, e.g. if you have two Localizations settings such as “Local” and “international” make sure that you don't have a country listed in both or else the set-up will of course become confused.
I have not upgraded from 2.1.2 simply because my store is operating OK so I have opted to leave well enough alone, I do not know if the file will still be OK for 2.1.4 you may need to check with support on that.
You could perhaps compare the code to your existing geoip.php file and try the changes out (after backing up the original file) and if it does not resolve your issues simply revert back to the original file.