something changes the name of the department automatically

[fabriceunko]

hello, I just saw that on my store, (cube cart 6.0.8) I have a problem.
something changes the name of the department. (store in France).
if a client registers and puts the department in a number or a name such as 75 or Paris, there a instead Alabam, Armed Forces Americas, or else that it brings! ..
see screen capture ..
can you help me? because very new to the php code
Thank you

[fabriceunko]

person to address my problem?

[bsmither]

These images are from what page?

[fabriceunko]

hello, images come from the administrator part, when I click on the number of a command. this fact is the change in the billing address is in the delivery address. department in the part of the address.
I do not know if this is related but I have noticed that there is often this change when the customer makes a number instead of the name of the department. because when I manually corrects ago figure. example: instead of 13 mouth of the Rhone.

[fabriceunko]

please.

[bsmither]

Please forgive me. I am sorry but I must ask that you find a friend who speaks English better than you, and have that person post what you are wanting to solve.

"number of a command" and "department" just do not make sense to me.

[fabriceunko]

Hello, sorry for my bad English. I will try to be clearer.
the images above are from here:
when I'm in my site's administration

I click unsettled orders, and order number a new command.

 

[bsmither]

I have read information that has me believe that "departments" in France is similar in concept to Counties in the UK, States in the USA, and Provinces in Canada.

I understand you to be saying that it is common for a French mailing address to include the name of the "department", and within the name of the department to include the department number.

Please make this edit. The following edit may be all that is needed, or there may be more edits.

In /admin/sources/orders.index.inc.php, near line 319

Find:
$overview_summary['country_d'] = is_numeric($overview_summary['country_d']) ? getCountryFormat($overview_summary['country_d'], 'numcode', 'name') : $overview_summary['country_d'];
$overview_summary['country'] = is_numeric($overview_summary['country']) ? getCountryFormat($overview_summary['country'], 'numcode', 'name') : $overview_summary['country'];
$overview_summary['state_d'] = is_numeric($overview_summary['state_d']) ? getStateFormat($overview_summary['state_d']) : $overview_summary['state_d'];
$overview_summary['state']  = is_numeric($overview_summary['state']) ? getStateFormat($overview_summary['state']) : $overview_summary['state'];

We will replace is_numeric(), which falsely identifies a State/County name that may contain a number as 'numerical' and finds the State based on that number.

Change to:
$overview_summary['country_d'] = ctype_digit($overview_summary['country_d']) ? getCountryFormat($overview_summary['country_d'], 'numcode', 'name') : $overview_summary['country_d'];
$overview_summary['country'] = ctype_digit($overview_summary['country']) ? getCountryFormat($overview_summary['country'], 'numcode', 'name') : $overview_summary['country'];
$overview_summary['state_d'] = ctype_digit($overview_summary['state_d']) ? getStateFormat($overview_summary['state_d']) : $overview_summary['state_d'];
$overview_summary['state']  = ctype_digit($overview_summary['state']) ? getStateFormat($overview_summary['state']) : $overview_summary['state'];

We will use ctype_digit() to test if the State/County and Country Code contains only digits. If so, then the value must therefore be associated with the CubeCart_geo_zone table - as opposed to a free-form entry.

 

[Dirty Butter]

I don't see what you want the replacement code to be, Bsmither.

 

[bsmither]

The stupid editor in these forums will crash (sort of) if I go to another browser or tab to get a web address that I want to create a link with. So, I have to post what I have compose so far, then go back to edit that post -- I can then get the link constructed. I then proceed to finish composing the rest of the post.

Although, I think there is the case where the editor uses the browser's "localstorage" to hold the editor's contents in situ, and thus allows for just abandoning the composition, reloading the entire forum page, and and then clicking inside the "quick Replay" area and the browser will populate the editor with the localstorage.

But the browser's localstorage can be switched off (which I am prone to do), so I do not want to get in the habit of depending on it.

I finished the post above.

[bsmither]

Maybe the above edit does not solve the initiating problem.

If the customer enters for the State/County/Department text field, 13 Bouches-du-Rhône, then the number portion may cause a problem later.

A test using is_numeric() seems to correctly determine that 13 Bouches-du-Rhône is not numerical, so the edit above is probably not necessary.

What we will need to see if the actual database contents. Please use a database utility such as phpMyAdmin to look at Cubecart_order_summary and find the order that is showing this problem.

What are the exact contents of the columns 'state' and 'state_d'?

 

[bsmither]

Ok, I think I found it. It has to do with the behavior of the MySQL database.

More later.

[bsmither]

The edit above is probably not necessary. So revert that file back to the way it was.

I may have found the real problem: please see https://github.com/cubecart/v6/issues/931

Please make this edit:

In the file /includes/functions.inc.php, near line 561:

Find:
function getStateFormat($input, $match = 'id', $fetch = 'name') {

On a new blank line below that, add:
if($match == 'id' && !ctype_digit($input)) return $input;

This will not fix existing orders where the address has already been "changed" to some other State name (such as Alabama). You may have to manually fix those yourself.

But any new orders where the customer has the opportunity to enter a "Department" that starts with a number should now stay that way. Hopefully.

[fabriceunko]

Good evening, I made the change above. I will come to you if the problem persists

[Dirty Butter]

There seems to be more to this, as we currently have a package going to Benfeld, France. The customer used 67 (by itself, with no words) as the "State". Our BCC copy of their order confirmation email shows the "State" as British Columbia. I Googled the correct Department for Benfeld, France, and changed the 67 to Bas-Rhin, which was accepted by our postage software.

I had replaced the 67 on the Order page with Bas-Rhin, but the address book entry is bas-rhin (Which makes me think that the Addressbook code dealt correctly with the 67).