WebsiteBaker Community Forum
WebsiteBaker Support (2.10.x) => Modules => Topic started by: rumen on November 12, 2017, 03:18:32 PM
-
Again problems with the Cyrillic in the new version of Bakery 1.83 under WB 2.10
Last time we added to the language files code that fixed the problem.
// ADDRESS FORM VALIDATION
$MOD_BAKERY['ADD_CHARSET'] = 'Cyrillic';
Now I added the same code, but fixed only half of the text. Where else I should enter that fix? to avoid that problem?
Уважаеми Румен Запрянов
Благодарим ви за вашата поръчка в lystoto.com.
Моля, вижте информацията за вашата поръчка:
Номер:
Име: Есенна наслада
Количество: 1
Цена: BGN 17.50
Сума: BGN 17.50
-------------------------------------
Междинен сбор: BGN 17.50
Цена за доставката: BGN 0.00
-------------------------------------
-------------------------------------
Общо: BGN 17.50
-------------------------------------
Ние ще доставим поръчката на адрес:
Румен Запрянов
Бусманци ул. Циклама 2
1520 София
876415004
Вие се отбелязали, че ще заплатите на куриер при получаването на поръчката.
Благодарим Ви, за доверието в нас. Заповядайте отново!
Поздрави,
lystoto.com
Regards,
Rumen
-
Look in your Template
<head>
<title>LYSTOTO.COM - Начало</title>
<meta http-equiv="Content-Type" content="text/html; charset=" />
<meta name="description" content="short description of the pages content" />
should be
<meta http-equiv="Content-Type" content="text/html; charset=">
parsed
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
MfG. Evaki
-
pls read a first the P.S.: in the bottom
what is it in your post - the email to the customer?
if i remeber correct, this overview comes directly from the invoice
the view_confirmation.p hp reads this invoice and split it into several parts, specially customer datas like adress, name etc
the summary for all item, price etc is called in bakery as ITEM_LIST and come's also from the invoice as part #14
everything in the invoice come's from the last step, before a customer buy the item's, where you have the BUY-Button - do you have there also problems????
P.S.: additional to the post from evaki
i'm sure, the problem is a missing entry in database table settings - something go'es wrong in the upgrade of wb, if the old version works also with UTF8, then the field default_charset in settings table is empty
please check this and add there utf8 if the field is empty
if this field there are empty, it's not needed to edit the template
-
I upgraded from Bakery 1.77 to 1.83, but didn't noticed any changes. I can't say if this is old issue or new, because right now I see it when start testing the bakery ... in the Database everything in Bakery was done manually, simply because some of the tables were with colation cp-1251, so I made them UTF8_general_ci but this didn't fixed the issue.
I will check the template settings again. But I don't think the issue comes from the template. If half of the text is OK and half is not .... the problen is not in the template.
-
The charset in the template are set:
<meta http-equiv="Content-Type" content="text/html; charset=<?php
if(defined('DEFAULT_CHARSET')) { echo DEFAULT_CHARSET; } else
{ echo 'utf-8'; }?>" />
-
looks, that you dont read my answer
i'm sure, the problem is a missing entry in database table settings - something go'es wrong in the upgrade of wb, if the old version works also with UTF8, then the field default_charset in settings table is empty
please check this and add there utf8 if the field is empty
-
Es macht für den Parser einen Unterschied -den sehr wahrscheinlichen DB-Fehler ganz unberücksichtigt- ob:
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
oder
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
Mein Hinweis bezog sich nur auf den fehlenden utf-8-Eintrag und den inkompatiblen Tag,
weshalb auch dort u.a. "parsed" steht.
Ich vermute eine Kombination aus mehreren möglichen Fehlern.
MfG. Evaki
-
I check the data base default charset in settings is UTF8
(http://lystoto.com/media/utf8.png)
-
the missing charset in meta-tag is (or was) confirmed, the question is WHY
simply because some of the tables were with colation cp-1251, so I made them UTF8_general_ci but this didn't fixed the issue.
only changing the table collation, did not changing anything in the table content - its important for the next new entry's, but it cannot change the old content.
<meta http-equiv="Content-Type" content="text/html; charset=<?php
if(defined('DEFAULT_CHARSET')) { echo DEFAULT_CHARSET; } else
{ echo 'utf-8'; }?>" />
since WB 2.8.3 SP7 not longer needed in this (extended) form, because, WB 2.8.3 SP7 & up can only work with utf8. short version of this line are
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
but it's also no problem, to work with the "old" code - if everything works
we know about this problem in the wb-upgrade and it's solved in the next wb-version, if nobody remove the fixed code.....
we know also: if there is a missing settings value in wb-settings - default charset, you have it also in every module, what use the mail-function, because also the emails using this charset
so0 the question again - where do you have this problem's? on the page? in the mails?
-
W3C Internationalizatio n Checker (https://validator.w3.org/i18n-checker/check?uri=http%3A%2F%2Flystoto.com%2F) (Y)
MfG. Evaki