Перейти к содержанию
aseven

[Решено] непонятки при переносе на новый сервак

Рекомендуемые сообщения

Добрый день!

 

До этого сайт отлаживался на хостинге Jino.

Т.к. сайт там выжирал лимиты и блочился - переносим на маленький VDS.

Версия PHP 5.4 (там такая же была), далее стандартно - nginx+fpm, mysql.

 

И вот такие ошибки при попытке оформить заказ:

Warning
: json_encode(): Invalid UTF-8 sequence in argument in
/var/www/admis/public_html/system/library/agoo/response.php
on line
387
Warning
: json_encode(): Invalid UTF-8 sequence in argument in
/var/www/admis/public_html/system/library/agoo/response.php
on line
387
Warning
: json_encode(): Invalid UTF-8 sequence in argument in
/var/www/admis/public_html/system/library/agoo/response.php
on line
387
Warning
: json_encode(): Invalid UTF-8 sequence in argument in
/var/www/admis/public_html/system/library/agoo/response.php
on line
387
Warning
: json_encode(): Invalid UTF-8 sequence in argument in
/var/www/admis/public_html/system/library/agoo/response.php
on line
387
Warning
: json_encode(): Invalid UTF-8 sequence in argument in
/var/www/admis/public_html/system/library/agoo/loader.php
on line
588
Warning
: json_encode(): Invalid UTF-8 sequence in argument in
/var/www/admis/public_html/system/library/agoo/loader.php
on line
588
Warning
: json_encode(): Invalid UTF-8 sequence in argument in
/var/www/admis/public_html/system/library/agoo/loader.php
on line
588
Warning
: json_encode(): Invalid UTF-8 sequence in argument in
/var/www/admis/public_html/system/library/agoo/loader.php
on line
588
Warning
: json_encode(): Invalid UTF-8 sequence in argument in
/var/www/admis/public_html/system/library/agoo/response.php
on line
387

 

Уже с ног сбились искать проблему.

default charset в php стоит.

В конфигах MySQL включено все про UTF8 тоже.

Сама БД - тоже Utf8 и collation в ней же.

 

Сборка opencart.pro Версия 2.1.0.2.2 , шаблон Revolution 3.1.2, корзина Simple 4.8.10

Зы: все честно приобретено на liveopencart если что.

 

Какие могут быть варианты? 

На прошлом хостинге, повторюсь, все работало!

Изменено пользователем aseven
добавил версию

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Приходят данные не UTF8

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

@aseven , а что это за модуль agoo? У вас все ошибки внутри его директории.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
21 минуту назад, Dotrox сказал:

@aseven , а что это за модуль agoo? У вас все ошибки внутри его директории.

 

Такого модуля отдельно нет. Поискал по установщикам - эту директорию JetCache от markimax создавал. 

Т.е. что-то с кэшированием связано.

 

Но! На прошлом хостинге-то все ок было).

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
12 минут назад, aseven сказал:

эту директорию JetCache от markimax создавал

Тогда и вопросы надо бы и ему адресовать. Может, он быстрее догадается, что там не так.

 

14 минут назад, aseven сказал:

Но! На прошлом хостинге-то все ок было).

Ну, поскольку версия php не менялась, то вариант с отсутствием расширения отпадает (начиная с 5.5 его надо ставить отдельно), да и ошибка была бы другой. Но есть ещё много чего, что могло поменяться и что каким-то образом (возможно, косвенным) могло повлиять на появление ошибки.

 

Выложите сюда те строки, которые указаны в ошибках и +10 строк перед ними, чтоб можно было понять хоть что именно там json_encode() пытается обработать и откуда эти данные приходят.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
4 минуты назад, Dotrox сказал:

Выложите сюда те строки, которые указаны в ошибках и +10 строк перед ними, чтоб можно было понять хоть что именно там json_encode() пытается обработать и откуда эти данные приходят.

 

        if (SC_VERSION > 15) {
        	$data_cache['cart'] = $this->cart->getProducts();
        }
		$data_cache['session'] = $session;
		$data_cache['url'] = $this->request->server['HTTP_HOST'] . $this->request->server['REQUEST_URI'];
		$data_cache['post'] = $this->request->post;
		$data_cache['get'] = $this->request->get;
        unset($data_cache['get']['_route_']);
		$hash = md5(json_encode($data_cache));

		$route_name = $this->config->get('config_language_id').'_'.$this->config->get('config_store_id');
		if (isset($this->request->get['route'])) {
			$route_name .= '_'.str_replace('/', '_', $this->request->get['route']);
		}

		unset($data_cache);

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Ну, по крайней мере теперь понятно, что база не при чём. Есть вероятность, что проблема может быть в настройках веб-сервера. Ну, или проблема была всегда, просто вы ещё не сталкивались с ней.

 

Добавьте перед

$hash = md5(json_encode($data_cache));

это:

$this->log->write($data_cache);

Повторите попытку оформить заказ, а затем сморите, что выведет в журнал ошибок. Там будет тот массив, который пытается обработать json_encode().

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
8 минут назад, Dotrox сказал:

Ну, по крайней мере теперь понятно, что база не при чём. Есть вероятность, что проблема может быть в настройках веб-сервера. Ну, или проблема была всегда, просто вы ещё не сталкивались с ней.

 

Повторите попытку оформить заказ, а затем сморите, что выведет в журнал ошибок. Там будет тот массив, который пытается обработать json_encode().

 

Да, выясняли как раз. Ноги растут от модуля eDost. 

 

                            [order] => Array
                                (
                                    [location] => Array
                                        (
                                            [country] => 0
                                            [region] => 16
                                            [city] => ������
                                            [zip] => 
                                        )

 

Там какой-то прикол с кодировкой самого их файла edost-class.php.

 

Но! На старом серваке же оно работало!

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
5 минут назад, aseven сказал:

Там какой-то прикол с кодировкой самого их файла edost-class.php.

Почему вы думаете, что вот это:

[city] => ������

из-за кодировки файла?

 

Теперь надо смотреть уже форму заказа, в каком формате из неё город отправляется.

 

8 минут назад, aseven сказал:

Но! На старом серваке же оно работало!

Добавьте на всякий случай в конфиг nginx в блок server вашего сайта это:

charset UTF-8;

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

@aseven а на сервере локаль какая? Залогиньтесь по SSH и в консоли напишите `locale`, `locale -a`

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Dotrox,

Короче, разобрались.

 

Цитирую:

Цитата

по-ходу глюк в php
This function has weird behavior regarding error reporting in PHP version 5.4 or lower. This kind of warning is raised only if you configure PHP with "display_errors=Off" (!?): "PHP Warning:  json_encode(): Invalid UTF-8 sequence in argument ..."

 

Цитата

// Warning not displayed, not logged
ini_set('display_errors', '1');

 

И все вылечилось.

 

Ваще жесть конечно, 2 дня (выходных) убили.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
20 minutes ago, aseven said:

Ваще жесть конечно, 2 дня (выходных) убили.

Ага. Хорошо ещё, что на старом сервере у вас 5.4 было, а не PHP3 :)

P.S. 5.6 - весьма. Не первый год уже, никаких нареканий. Зря за 5.4 держитесь.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
3 минуты назад, rb2 сказал:

Ага. Хорошо ещё, что на старом сервере у вас 5.4 было, а не PHP3 :)

P.S. 5.6 - весьма. Не первый год уже, никаких нареканий. Зря за 5.4 держитесь.

 

Стоп, я думал что 5.4 это самый безглючный вариант для OpenCart 2.1. Это не так?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
3 часа назад, aseven сказал:

я думал что 5.4 это самый безглючный вариант для OpenCart 2.1. Это не так?

На 5.6 он отлично работает, как и все предыдущие и последующие версии ОК (даже 1.5.3, из того, что лично переносил).

Кстати, непонятно откуда вы вообще взяли подобные мысли: до версии 2.2 включительно минимальной версией php была 5.3, начиная с 2.3 - минимальная 5.4. Так что никакой связи между ОК 2.1 и php 5.4 - вообще нет (в случае 2.3 можно было бы ещё подумать, что вы перепутали минимальную с рекомендуемой версией).

 

 

4 часа назад, aseven сказал:

Короче, разобрались.

Не разобрались! Если вы внимательно прочитаете этот комментарий в доках, то поймёте, что там не говориться, что ошибка возникает на ровном месте, там говориться только о странностях с её логированием, а именно о том, что она попадает в лог только при выключенном показе ошибок, а иначе она и не выводится и не логируется.

То есть, у вас по прежнему есть проблема с не UTF-8 символами, с которой надо разобраться, потому что иначе вам либо придёться включить вывод ошибок, чтоб эта ошибка перестала записываться в лог (это вы уже сделали и это не сильно хорошо для работающего магазина), либо у вас постоянно в лог будут сыпаться подобные ошибки (в чём тоже ничего хорошего нет и лог будет зря разрастаться).

 

 

4 часа назад, aseven сказал:

И все вылечилось.

Вы просто воспользовались хаком, позволяющим скрыть эту ошибку из логов, но проблема с кодировкой осталась.

 

Кстати, тут ещё есть вопрос, что возвращает json_encode() в случае наличия неправильных символов во входящих данных: я попробовал на 5.6 и мне вернуло пустую строку. То есть, хеши при оформлении заказа во всех случаях будут совпадать (если там всегда неправильная кодировка), что может привести к непредсказуемым результатам. Правда, непонятно зачем вообще кешировать данные заказа (да и просто любые POST запросы), но это уже отдельный вопрос.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
21 час назад, Dotrox сказал:

. Правда, непонятно зачем вообще кешировать данные заказа (да и просто любые POST запросы), но это уже отдельный вопрос.

Это не кеширование post запросов - а хеширование ;)
Представьте вы на странице формы, не правильно заполнили, ну дальше я думаю обьяснять не надо если не хешировать  post то отдастся страница без предупреждений об ошибках заполнения. Когда есть сборщик "мусора" и файлы кеша систематически разложены по папкам, то это никак не отразится не на чем.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
В 16.04.2017 в 20:44, rb2 сказал:

@aseven а на сервере локаль какая? Залогиньтесь по SSH и в консоли напишите `locale`, `locale -a`

 

Под моим пользователем вот так (сайт вращается под другим юзером с /bin/false) :

 

LANG=ru_RU.UTF-8
LANGUAGE=
LC_CTYPE="ru_RU.UTF-8"
LC_NUMERIC="ru_RU.UTF-8"
LC_TIME="ru_RU.UTF-8"
LC_COLLATE="ru_RU.UTF-8"
LC_MONETARY="ru_RU.UTF-8"
LC_MESSAGES="ru_RU.UTF-8"
LC_PAPER="ru_RU.UTF-8"
LC_NAME="ru_RU.UTF-8"
LC_ADDRESS="ru_RU.UTF-8"
LC_TELEPHONE="ru_RU.UTF-8"
LC_MEASUREMENT="ru_RU.UTF-8"
LC_IDENTIFICATION="ru_RU.UTF-8"
LC_ALL=

в выводе locale -a есть много чего, а в частности вот это:

ru_RU
ru_RU.cp1251
ru_RU.koi8r
ru_RU.utf8
ru_UA
ru_UA.utf8

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

У меня были проблемы, когда локаль была ru_RU.UTF-8. После смены на en_US.UTF-8 (или en_GB) все проблемы с русскими кодировками мгновенно исчезли.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

вот что ответил админ который сервак ставил

 

Пл-умолчанию на сервере en_US.utf-8

У тебя ru_RU из-за клиента ( локали могут индивидуально выбираться для каждой сессии пользователя в соответствии с настройками клиента ). 

Ты спроси насчёт кодировки файла, который я тебе, про который я тебе писал - edost-class.php - что там кодировка double encoded to uft-8 from iso8859-5 и что строка, из-за которой не хочет работать json-encode - этой же кодировки.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
11 часов назад, aseven сказал:

edost-class.php - что там кодировка double encoded to uft-8 from iso8859-5

Если в этом файле не хранится список городов, его кодировка значения вообще не имеет (а точнее, сойдёт любая латиница, которую сможет прочитать интерпретатор php), а если б список городов там был, то оно б уже в форме заказа криво выводилось.

Кроме того, таких кодировок не бывает. У файла кодировка может быть либо uft-8, либо iso8859-5, но не то, что здесь написано.

 

Вообще, без ссылки на сайт бессмысленно дальше гадать. Надо посмотреть на форму оформления заказа и что она на сервер отправляет из браузера.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Для публикации сообщений создайте учётную запись или авторизуйтесь

Вы должны быть пользователем, чтобы оставить комментарий

Создать учетную запись

Зарегистрируйте новую учётную запись в нашем сообществе. Это очень просто!

Регистрация нового пользователя

Войти

Уже есть аккаунт? Войти в систему.

Войти

  • Последние посетители   0 пользователей онлайн

    Ни одного зарегистрированного пользователя не просматривает данную страницу

×

Важная информация

На нашем сайте используются файлы cookie и происходит обработка некоторых персональных данных пользователей, чтобы улучшить пользовательский интерфейс. Чтобы узнать для чего и какие персональные данные мы обрабатываем перейдите по ссылке. Если Вы нажмете «Я даю согласие», это означает, что Вы понимаете и принимаете все условия, указанные в этом Уведомлении о Конфиденциальности.