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

aseven · 16 квітня 2017

Добрый день!

До этого сайт отлаживался на хостинге 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 если что.

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

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

Змінено 16 квітня 2017 користувачем aseven
добавил версию

16 квітня 2017

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

Dotrox · 16 квітня 2017

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

aseven · 16 квітня 2017

21 минуту назад, Dotrox сказал:

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

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

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

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

Dotrox · 16 квітня 2017

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

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

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

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

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

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

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

aseven · 16 квітня 2017

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);

Dotrox · 16 квітня 2017

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

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

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

это:

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

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

aseven · 16 квітня 2017

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

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

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

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

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

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

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

Dotrox · 16 квітня 2017

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

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

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

[city] => ������

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

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

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

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

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

charset UTF-8;

rb2 · 16 квітня 2017

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

aseven · 16 квітня 2017

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 дня (выходных) убили.

rb2 · 16 квітня 2017

20 minutes ago, aseven said:

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

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

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

aseven · 16 квітня 2017

3 минуты назад, rb2 сказал:

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

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

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

rb2 · 16 квітня 2017

С чего бы это?

Dotrox · 16 квітня 2017

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 запросы), но это уже отдельный вопрос.

markimax · 17 квітня 2017

21 час назад, Dotrox сказал:

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

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

aseven · 17 квітня 2017

В 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

rb2 · 17 квітня 2017

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

aseven · 19 квітня 2017

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

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

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

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

Dotrox · 19 квітня 2017

11 часов назад, aseven сказал:

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

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

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

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

Вхід

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

Recommended Posts

Надіслати

Поділитися на інших сайтах

Гість

Надіслати

Поділитися на інших сайтах

Надіслати

Поділитися на інших сайтах

Надіслати

Поділитися на інших сайтах

Надіслати

Поділитися на інших сайтах

Надіслати

Поділитися на інших сайтах

Надіслати

Поділитися на інших сайтах

Надіслати

Поділитися на інших сайтах

Надіслати

Поділитися на інших сайтах

Надіслати

Поділитися на інших сайтах

Надіслати

Поділитися на інших сайтах

Надіслати

Поділитися на інших сайтах

Надіслати

Поділитися на інших сайтах

Надіслати

Поділитися на інших сайтах

Надіслати

Поділитися на інших сайтах

Надіслати

Поділитися на інших сайтах

Надіслати

Поділитися на інших сайтах

Надіслати

Поділитися на інших сайтах

Надіслати

Поділитися на інших сайтах

Надіслати

Поділитися на інших сайтах

Створіть аккаунт або увійдіть для коментування

Створити обліковий запис

Вхід

Зараз на сторінці 0 користувачів

Покупцям

Розробникам

Корисна інформація

Останні розширення

Important Information