Paginate by Letter issue of Countries list in Multilingual Admin

[mc12345678]

In it is indeed the file coutries.php. Sorry about the confusion.

It is very confusing that the value of $_GET['page'] is correct before the execution of the initial line#8

require 'includes/application_top.php';

and it is an empty string only for the alternative alphabet after that.

Again, because the data for those other country names in the database are not utf-8ish. By that I mean they are neither utf-8 nor utf-8mb4, which are the two encodings typically used now by zen Cart.

As previously stated, these could be updated through one or more sql statements. Either the errant entries get converted or a separate query is run to update the data in the database with utf-8ish entry. This can be done via tools, install sql patches.

[carlwhat]

Again, because the data for those other country names in the database are not utf-8ish. By that I mean they are neither utf-8 nor utf-8mb4, which are the two encodings typically used now by zen Cart.

As previously stated, these could be updated through one or more sql statements. Either the errant entries get converted or a separate query is run to update the data in the database with utf-8ish entry. This can be done via tools, install sql patches.

personally i was never a fan of this letter pagination idea.

that said, props to @mc12345678 for figuring this bug out.

i would also look at the zones page as i think if the encoding is wrong, that page may not work as well.

best.

[mc12345678]

Again, because the data for those other country names in the database are not utf-8ish. By that I mean they are neither utf-8 nor utf-8mb4, which are the two encodings typically used now by zen Cart.

As previously stated, these could be updated through one or more sql statements. Either the errant entries get converted or a separate query is run to update the data in the database with utf-8ish entry. This can be done via tools, install sql patches.

And I'm willing to offer more specific assistance; however, need more details about what capabilities you have available, what data is known about the problem country names, what language is involved, etc...

My thought on the "replacement" style query, in absence of detailed database data and if there is only one other language, then the query could do a substitution of the countries_name record for the country that has the same countries_iso_code_3 but is not the english equivalent. E.g.:

UPDATE countries SET countries_name = 'FOREIGN COUNTRY NEW NAME' WHERE countries_iso_code_3 = 'XYZ' AND countries_name != 'ENGLISH NAME OF COUNTRY';

[swguy]

If the consensus is that countries.php line 11 is a bug (or needs additional logic such as a notifier), please PR. Thanks!

[mc12345678]

In it is indeed the file coutries.php. Sorry about the confusion.

It is very confusing that the value of $_GET['page'] is correct before the execution of the initial line#8

require 'includes/application_top.php';

and it is an empty string only for the alternative alphabet after that.

If the consensus is that countries.php line 11 is a bug (or needs additional logic such as a notifier), please PR. Thanks!

Based on the report of the above investigation, line 11 in admin/countries.php does not appear to be the issue but rather sanitization executed within admin/includes/application_top.php.

[vasilt]

As pointed out by mc12345678, the problem is in the sanitization within admin/includes/application_top.php. When I revert the value of $_GET['page'] back to its original value after the sanitization, everithing works as expected. The table "countries" is utf8 and the column "countries_name" is utf8. I converted the column to BLOB and checked the hex values. They correspond to utf-8. For example the hex code for Zimbabwe in English is: 5A 69 6D 62 61 62 77 65 and in Bulgarian is: D0 97 D0 B8 D0 BC D0 B1 D0 B0 D0 B1 D0 B2 D0 B5. This is exactly the the value of the BLOB field.

[mc12345678]

As pointed out by mc12345678, the problem is in the sanitization within admin/includes/application_top.php. When I revert the value of $_GET['page'] back to its original value after the sanitization, everithing works as expected. The table "countries" is utf8 and the column "countries_name" is utf8. I converted the column to BLOB and checked the hex values. They correspond to utf-8. For example the hex code for Zimbabwe in English is: 5A 69 6D 62 61 62 77 65 and in Bulgarian is: D0 97 D0 B8 D0 BC D0 B1 D0 B0 D0 B1 D0 B2 D0 B5. This is exactly the the value of the BLOB field.

Actually, you've just done the first step of what may resolve your issue. You've converted a nonbinary datatype to a binary datatype. Next would be to convert that column back to the utf-8ish datatype expected for the column... would expect the issue to be resolved for this problem.

[vasilt]

I explicitly changed the encoding of the "countries_name" field of the "countries" table by applying the following two statements in phpMyadmin:
ALTER TABLE countries MODIFY countries_name BLOB
ALTER TABLE countries MODIFY countries_name VARCHAR(64) CHARACTER SET utf8
and this didn't solve the problem

[vasilt]

I found a solution though I am not sure if it compromises site security. The file is admin/includes/classes/AdminRequestSanitizer.php and the line is 343. If the regular expression is modified to include the characters of the alternative alphabet, letter pagination works as expected.