«1С-Битрикс: Управление сайтом» — одна из самых популярных коммерческих CMS. Как и в случае с любой другой CMS, при работе с Битриксом возникают разные ошибки, мешающие нормальной работе сайта. Выявить их можно с помощью встроенного функционала проверки системы в панели администратора Битрикс.
Чтобы запустить проверку системы, перейдите в панель администратора по ссылке https://example.com/bitrix/admin (замените example.com на ваш домен), введите логин и пароль учетной записи администратора сайта, перейдите в Настройки — Инструменты — Проверка системы и нажмите на кнопку Начать тестирование. Дождитесь окончания проверки. В форме Проверка системы могут быть ошибки, которые, на первый взгляд, не влияют на работу сайта, однако требуют внимания владельца или системного администратора сайта.
В данной статье рассмотрим способы устранения популярных ошибок, возникающих в CMS Битрикс.
- Ошибка «The script encountered an error and will be aborted. To view extended error messages, enable this feature in .settings.php.» при переходе на сайт
- «Замечание. Агенты выполняются на хитах, рекомендуется перевести выполнение агентов на cron» при проверке системы
- Ошибка работы с сокетами при проверке системы
- Ошибка! Не работает «Отправка почты» и «Отправка почтового сообщения больше 64Кб» при проверке системы
- «Служебные скрипты в корне сайта. Ошибка! Файл существует» при проверке системы
- Ошибка «Загрузка файла» и «Загрузка файла больше 4Мб» при проверке системы
Ошибка «The script encountered an error and will be aborted. To view extended error messages, enable this feature in .settings.php.» при переходе на сайт
Такая ошибка в большинстве случаев означает некорректное подключение к базе данных. В первую очередь проверьте, работает ли СУБД, введя следующую команду в терминал:
# systemctl status mysql
Если СУБД работает, проверьте файлы, расположенные в /home/bitrix/www/bitrix/.settings.php и /home/bitrix/www/bitrix/php_interface/dbconn.php (при необходимости замените /home/bitrix/www на корневую директорию вашего проекта, далее в статье будут использованы относительные пути вида /bitrix/php_interface/dbconn.php). В этих файлах указываются доступы для подключения к базе данных сайта.
Для файла .settings.php
'host' => 'localhost', 'database' => 'database_name', 'login' => 'user_name', 'password' => 'secret_password',
Для файла dbconn.php
$DBHost = "localhost"; $DBLogin = 'user_name'; $DBPassword = 'secret_password’; $DBName = "database_name";
Проверьте корректность указанных данных:
- хост базы данных (должен быть localhost, если СУБД установлена локально),
- название базы данных (замените в обоих файлах
database_nameна название своей базы данных), - имя пользователя базы данных (замените
user_nameна имя своего пользователя базы данных) - и пароль пользователя базы данных (замените
secret_passwordна пароль пользователя вашей базы данных).
Иногда бывает, что при развертывании сайта из бэкапа на новом сервере вместо данных указываются звездочки. В таком случае просто укажите свои данные в обоих файлах.
«Замечание. Агенты выполняются на хитах, рекомендуется перевести выполнение агентов на cron» при проверке системы
При проверке системы Битрикс часто возникает замечание выполнения агентов на cron. Данное замечание не мешает работе сайта, однако может повлиять на выполнение разных функций вашего проекта, например, на отправку почты.
Как правило, для настройки выполнения агентов на cron достаточно следовать рекомендациям проверки системы. Для этого нажмите на вопросительный знак справа от уведомления:
Однако такой способ срабатывает не всегда. Если в файле /bitrix/php_interface/dbconn.php есть строка define('BX_CRONTAB_SUPPORT', true); и в cron есть задание на ежеминутный запуск скрипта /var/www/bitrix/modules/main/tools/cron_events.php, попробуйте следующее решение.
Отключим выполнение агентов на хитах, для этого в панели администратора Битрикс переходим в Настройки — Инструменты — Командная PHP-строка, вводим следующую команду и нажимаем Выполнить:
COption::SetOptionString("main", "agents_use_crontab", "N");
echo COption::GetOptionString("main", "agents_use_crontab", "N");
COption::SetOptionString("main", "check_agents", "N");
echo COption::GetOptionString("main", "check_agents", "Y");
Результат выполнения PHP-команды должен быть «NN».
Далее в файле /bitrix/php_interface/dbconn.php закомментируем следующие строки (добавьте перед строками знак #):
define("BX_CRONTAB_SUPPORT", true);
define("BX_CRONTAB", true);
После чего в этот же файл dbconn.php добавьте строки:
if(!(defined("CHK_EVENT") && CHK_EVENT===true))
define("BX_CRONTAB_SUPPORT", true);
Далее необходимо из учетной записи владельца сайта (если вы работаете в консоли сервера из-под учетной записи root, что не рекомендуется, после создания файла измените владельца файла с помощью команды chown) создать новый файл cron_events.php в директории /bitrix/php_interface/ и добавить в него следующий код:
<?php
$_SERVER["DOCUMENT_ROOT"] = realpath(dirname(__FILE__)."/../..");
$DOCUMENT_ROOT = $_SERVER["DOCUMENT_ROOT"];
define("NO_KEEP_STATISTIC", true);
define("NOT_CHECK_PERMISSIONS",true);
define('BX_NO_ACCELERATOR_RESET', true);
define('CHK_EVENT', true);
define('BX_WITH_ON_AFTER_EPILOG', true);
require($_SERVER["DOCUMENT_ROOT"]."/bitrix/modules/main/include/prolog_before.php");
@set_time_limit(0);
@ignore_user_abort(true);
CAgent::CheckAgents();
define("BX_CRONTAB_SUPPORT", true);
define("BX_CRONTAB", true);
CEvent::CheckEvents();
if(CModule::IncludeModule('sender'))
{
BitrixSenderMailingManager::checkPeriod(false);
BitrixSenderMailingManager::checkSend();
}
require($_SERVER['DOCUMENT_ROOT']."/bitrix/modules/main/tools/backup.php");
CMain::FinalActions();
?>
После того, как файл создан с нужными правами, добавляем его в cron. Обязательно делаем это для владельца сайта, так как задания cron для пользователя root могут стать серьезной угрозой безопасности для сайта и сервера. Выполним следующую команду (в нашем случае владелец сайта — bitrix, замените это значение на имя пользователя своего сайта при необходимости):
# crontab -ubitrix -e
Откроется файл с заданиями crontab пользователя сайта. Вставьте следующую строку:
*/1 * * * * /usr/bin/php -f /home/bitrix/www/bitrix/php_interface/cron_events.php
В данной строке значение */1 * * * * означает выполнение скрипта раз в минуту, вы можете скорректировать частоту выполнения в зависимости от ваших требований к проекту.
Путь /usr/bin/php — путь для PHP, оставьте его таким же, если у вас на сервере нет альтернативных версий PHP. Если вы используете панель ISPmanager, возможно, ваш сайт работает на альтернативной версии PHP. Проверить версию можно в панели ISPmanager, а узнать корректный путь для PHP — с помощью команды whereis php в консоли сервера. Например, для альтернативной версии PHP 8.1 путь может быть таким: /opt/php81/bin/php. Замените путь к скрипту /home/bitrix/www/bitrix/php_interface/cron_events.php на свой в случае необходимости.
Если в cron есть запись для выполнения скрипта /var/www/bitrix/modules/main/tools/cron_events.php — ее лучше закомментировать.
Ошибка работы с сокетами при проверке системы
При проверке системы в панели администратора Битрикс может возникнуть ошибка «Работа с сокетами. Ошибка! Не работает».
Также из-за ошибки работы с сокетами другие тесты проводятся некорректно, выдавая ошибку «Замечание. Не удалось проверить из-за ошибки в работе с сокетами».
В большинстве случаев такая ошибка появляется после переноса проекта на новый сервер или при развертывании проекта на локальном компьютере для тестирования. Возникает данная ошибка из-за того, что IP-адрес сервера отличается от IP-адреса, указанного в А-записях домена на серверах DNS. Если вы переносите проект на новый сервер, необходимо указать IP-адрес нового сервера в А-записях и дождаться глобального обновления DNS.
Если А-записи указаны корректно, возможно в файле /etc/hosts на сервере указан неверный IP для вашего домена. Проверьте файл и укажите правильное значение:
1.2.3.4 example.com
Замените 1.2.3.4 на IP адрес вашего сервера, а example.com на доменное имя вашего сайта.
Бывает, что на сервере может возникнуть проблема с корневыми сертификатами. Можно попробовать обновить их. В CentOS 7 ведите в консоли сервера:
# yum install ca-certificates -y # update-ca-trust
Ошибка! Не работает «Отправка почты» и «Отправка почтового сообщения больше 64Кб» при проверке системы
Из описания ошибки понятно, что она означает. В большинстве случаев для устранения данной ошибки требуется вмешательство системного администратора или технической поддержки Битрикс. Проблем, из-за которых почта не работает, много. Они могут быть на стороне сервера, в настройках проекта, либо из-за некорректно работающих модулей отправки почты.
Битрикс использует стандартную функцию php mail() для отправки почты, однако нередко используются другие способы, например, через внешний почтовый сервер. Для проверки работы php mail() можно воспользоваться инструкцией из ответов на часто задаваемые вопросы на форуме Битрикс.
Также можно выполнить проверку с помощью следующего кода PHP (вставьте его в командную строку PHP в панели администратора Битрикс):
$mail="test@testmail.ru"; // укажите ваш почтовый ящик, на который нужно отправить тестовое письмо
$subject ="test" ; // укажите любую тему письма
$text= "test message"; // укажите любой текст письма
if( mail($mail, $subject, $text) )
{
echo 'Письмо отправлено!'; }
else{
echo 'Ошибка! Не отправлено';
}
Если письмо не пришло, но вы получили уведомление «Письмо отправлено», значит, письма уходят и проблема в настройках CMS либо в модуле отправки почты. В данном случае можно обратиться в техподдержку Битрикс для выявления проблем в настройках CMS или к разработчику модуля отправки почты.
Не исключено, что письмо просто попало в спам. Можно попробовать отправить на другой почтовый ящик (с другим почтовым доменом). Если письмо пришло — значит, адрес отправителя в черном списке почтового домена, до которого письмо не дошло. Если письмо не дошло — возможно, ваш почтовый домен или IP-адрес попали в глобальные черные списки.
Если письмо не пришло, а вы получили уведомление «Отправка не удалась» — необходимо более детальное изучение проблемы. В таком случае потребуется вмешательство системного администратора.
«Служебные скрипты в корне сайта. Ошибка! Файл существует» при проверке системы
Такая ошибка говорит о наличии в корне сайта служебных скриптов, например, restore.php. Данные скрипты, как правило, добавляют временно для проведения каких-либо работ (например, restore.php — для восстановления сайта из резервной копии). Так или иначе, после выполнения работ такие скрипты необходимо удалить с сервера, так как они представляют угрозу безопасности сайту и данным.
Ошибка «Загрузка файла» и «Загрузка файла больше 4Мб» при проверке системы
Проверка системы Битрикс загружает файл размером более 4Мб. В большинстве случаев такая ошибка говорит об ограничениях в параметре upload_max_filesize для PHP.
Необходимо в файле конфигурации PHP установить данное значение выше 4Мб и перезапустить веб-сервер. В зависимости от окружения файл конфигурации PHP может находится в разных местах. Обычно данное значение устанавливается в файле /etc/php.ini.
Если вы используете панель ISPmanager — поправить конфигурацию можно прямо в ней: выберите нужный сайт, нажмите на кнопку PHP в верхней панели, найдите параметр upload_max_filesize и укажите нужное значение. Если вы используете окружение BitrixVM, необходимо вносить изменения в специальные файлы конфигурации, чтобы после перезагрузки сервера они не вернулись в исходное состояние. Подробнее можете узнать по ссылке.
Материал из Wiki — Iphoster — the best ever hosting and support. 2005 — 2023
Перейти к:навигация, поиск
Bitrix — Загрузка файла — Ошибка Не работает — как исправить
Если при тестировании возникает ошибка вида:
Загрузка файла Ошибка! Не работает
то нужно проверить права на папку: bitrix/tmp/ и поставить ей права 777:
# chmod 777 bitrix/tmp/
Источник — https://wiki.iphoster.net/index.php?title=Bitrix_-_Загрузка_файла_-_Ошибка_Не_работает&oldid=9529
|
Пользователь 102162 Посетитель Сообщений: 102 |
Добрый день. Помогите решить проблему. Не могу загрузить фотографии большого размера в подробный анонс (а точнее превышающих 128кб, вычислил методом подбора). Тестирование конфигурации показало ошибку на пункте: Загрузка файла больше 4Мб. При этом хочу заметить, что параметры php.ini в порядке. Вариант о недостатке места на диске тоже отпадает (ещё около 8ГБ свободного). Блокировка NGFIX — также отпадает (напряг техподдержку хостинга чтобы проверили параметры, а потом и вовсе его временно отключили — чтобы проверить в нем причина или нет — не помогло). И так вопрос: какие ещё настройки могут отвечать за ограничения размера загружаемого файла? |
|
Пользователь 50911 Посетитель Сообщений: 95 |
#2 0 08.11.2013 13:20:57
посмотрите там какие параметры у upload_max_filesize |
||
|
Пользователь 102162 Посетитель Сообщений: 102 |
Я же в 1 сообщении все написал, |
|
Пользователь 102162 Посетитель Сообщений: 102 |
Сам разобрался. Для тех, кто возможно, столкнется с подобной проблемой… Нужно прописать параметр FcgidMaxRequestLen, иначе нельзя через браузер загружать файлы превышающие размер 128КБ. Это ограничение возникает если сайт работает под управлением ISP Manager как CGI/FastCGI. Можно прописать данный параметр в файле httpd.conf (в моем случае, он располагался по адресу /etc/httpd/conf), в этом файле нужно отредактировать параметр, либо добавить строку FcgidMaxRequestLen 107374182 Число 107374182 позволяет загружать файлы объемом до 1Гб, делает рестарт и проблема решена. Ещё один из вариантов, можно отредактировать файл fcgid.conf <IfModule mod_fcgid.c> |
|
Пользователь 107617 Заглянувший Сообщений: 1 |
Для тех, кто использует NGINX: В файл nginx.conf, в секцию http, добавить/изменить: |
|
Пользователь 125253 Эксперт Сообщений: 435 |
Антон Водолазский спасибо. Долго возились после переустановки ОС. Наткнулись на ваш пост) |
|
Пользователь 52657 Постоянный посетитель Сообщений: 114 |
Артем Осипов, Спасибо за подсказку. |
|
Пользователь 194259 Заглянувший Сообщений: 29 |
Большое спасибо! Проблема решена! |
|
Пользователь 336230 Заглянувший Сообщений: 3 |
Артем Осипов, Спасибо. Проблема решена. |
|
Пользователь 94067 Заглянувший Сообщений: 9 |
#10 0 07.02.2016 20:28:57 |
|
Пользователь 162578 Заглянувший Сообщений: 13 |
#11 0 10.03.2016 13:16:42 Артем Осипов,спасибо за подсказку! |
|
Пользователь 449 Постоянный посетитель Сообщений: 101 |
#12 0 04.08.2016 14:41:01
FcgidMaxRequestLen 1073741824 скорее http://webdoka.ru |
||
|
Пользователь 449 Постоянный посетитель Сообщений: 101 |
#13 0 04.08.2016 14:49:26 вот еще по теме Между тегами <IfModule mod_fcgid> и </IfModule> добавляем: IPCCommTimeout — устанавливает время доступа к скрипту от IP адреса, после которого работа процесса будет прервана. Стандартное значение — 40 секунд. |
|
Пользователь 316487 Заглянувший Сообщений: 1 |
#14 0 23.06.2017 17:56:06 Спасибо, рабочие оба варианта! |
|
Пользователь 33448 Посетитель Сообщений: 23 |
#15 0 16.01.2019 10:16:37
Антон, спасибо, помог Ваш вариант. Такой же случай — сайт работает под управлением ISP Manager как CGI/FastCGI. Добавил строку в httpd.conf и всё взлетело ) Носорог, как известно, плохо видит. Но при его весе — это не его проблемы. |
||
|
Пользователь 106725 Заглянувший Сообщений: 3 |
#16 0 18.01.2019 00:55:10 |
|
Пользователь 196067 Заглянувший Сообщений: 1 |
#17 0 14.04.2019 11:17:09
Спасибо работает |
||
|
Пользователь 2532517 Заглянувший Сообщений: 3 |
#18 0 12.05.2019 07:14:33 Спасибо! Одной проблемой стало меньше. |
|
Пользователь 4177500 Заглянувший Сообщений: 1 |
#19 0 28.07.2020 15:47:05
Прошло 7 лет, но до сих пор актуально. Спасибо |
||
|
Пользователь 3436271 Заглянувший Сообщений: 1 |
#20 0 28.09.2020 13:41:42 Спасибо большое, минус тех.поддержке особенно инженеру Александра Больнова |
|
Пользователь 2940905 Заглянувший Сообщений: 5 |
#21 0 08.04.2021 15:32:49 Помогло, спасибо! |
Выгрузка на сайт завершилась с ошибками. import.xml: Произошла ошибка на стороне сервера. Получен неизвестный статус импорта.
Увидели такую ошибку и думаете «в коде кто-то накосячил»? А вот совсем не факт.
Об удивительной причине по которой обмен 1С с сайтом может неожиданно перестать работать я и хочу рассказать.
А началось все довольно безобидно. Позвонил старый клиент у которого уже года 2-3 работает магазин в связке с 1С и пожаловался что обмен перестал работать. Полез я к нему в 1С и вижу, что обмен действительно падает причем с разными ошибками и на разных файлах.
Первое что сделали — перешли на более мощный тариф хостинга. Половина зоопарка ошибок исчезла. Однако ошибка
Выгрузка на сайт завершилась с ошибками.
import.xml: Произошла ошибка на стороне сервера. Получен неизвестный статус импорта.
Неверный тип файла, либо превышен максимальный размер файлаНеверный тип файла, либо превышен максимальный размер файла
осталась и уходить не собиралась.
Пробовали выгружать и на тиражный магазин и на VDS на который другая 1С прекрасно все грузит — везде одна и та же ошибка.
В итоге обратились в поддержку Битрикса. Судя по оперативности и точности ответов поддержка знает о проблеме. А суть ответов была в следующем: поддержка вставила отладочную печать и попросила сделать выгрузку.
По результатам выгрузки в консоли 1С появилась отладочная информация вида
Array ( [name] => 04f5da44f3fe11e297cb002215a2039c_04f5da47f3fe11e297cb002215a2039c.jpg [size] => 3789 [tmp_name] => /home/i/mysite/public_html/upload/tmp/1ec/04f5da44f3fe11e297cb002215a2039c_04f5da47f3fe11e297cb002215a2039c.jpg [type] => application/octet-stream [COPY_FILE] => Y [description] => [copy] => 1 [MODULE_ID] => iblock )
Отсюда можно видеть, что одна из картинок имеет mimetype: application/octet-stream.
Далее по названию картинки вычисляем (например, можно в import.xml поискать по названию картинки) нехороший товар, пересохраняем его картинку в любом графическом редакторе и все работает.
Кому интересно — вся отладка заключается в изменении файла /bitrix/modules/main/classes/general/file.php:
после каждого вызова
return GetMessage("FILE_BAD_TYPE");
нужно вставить
Попросил поддержку исправить этот баг в импорте, но мы то с вами знаем сколько такие неважные исправления могут делаться. Поэтому я просто оставлю это сообщение здесь. Возможно кому-то поможет сэкономить время.
Назад в раздел
При подготовке сервера под хостинг сайта на 1С Bitrix всплывают ошибки, с которыми я никогда не сталкивался при работе с другими CMS. Здесь я распишу что надо поменять, чтобы обмен с сайтом и upload файлов и картинок успешно выполнились.
Если честно, то Bitrix очень капризный продукт и требует очень точной настройки, для начинающих есть варианты уже с готовыми виртуальными образами, на которых развернут CentOS и Bitrix: Веб-окружение. Но если вы привыкли работать с другим дистрибутивом (лично я предпочитаю Debian и Ubuntu), то придется поковыряться в конфигах ручками.
Итак, в Apache максимальный размер файлов указывается либо в php.ini (не у всех есть доступ к этому файлу), либо напрямую в .htaccess. В моей статье Все про файл .htaccess я подробно расписывал все настройки. Ну а мы в .htaccess допишем:
php_value upload_max_filesize 10M
php_value post_max_size 10M
Я уже было решил, что проблема решена, но проверка системы также ругалась на максимальный размер файлы.
Причина оказалась в связке Nginx+Apache. Так как Nginx работает кэширующим фронт-энд сервером, то он работает изначально по своим правилам, а затем по этим правилам решает, передавать ли файл дальше в Apache или нет. Логи ясно показали ошибку
тут будет скрин или текст логов, сейчас проблема решена и естественно и нет ошибки. верну обратно и сделаю скрин
Путем недолгих поисков в интернете увидел правильные настройки виртуального хоста Nginx, с указанием максимального размера файла, который Nginx может передать бэкенд-серверу. Добавляем в /etc/nginx/sites-available/example.org.conf следующие директивы в блок настроек прокси
proxy_buffering off;
client_max_body_size 10m;
Перезапускаем службу и проверяем результат также через проверку системы Bitrix.
На сайте были такие настройки. У меня они чутка отличаются
proxy_pass http://127.0.0.1:8080/;
proxy_redirect off;
proxy_buffering off
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
client_max_body_size 10m;
client_body_buffer_size 128k;
proxy_connect_timeout 90;
proxy_send_timeout 6000;
proxy_read_timeout 6000;
proxy_buffer_size 4k;
proxy_buffers 4 32k;
proxy_busy_buffers_size 64k;
proxy_temp_file_write_size 64k;
Отблагдарить автора статьи также можно переводом, +100 вам в карму!
apache bitrix client_max_body_size htaccess nginx php_value post_max_size proxy_buffering server upload_max_filesize ошибки сайт
А у вас поддержка лицензии активная? В принципе случай когда можно обратится в ТП Битрикс. И лучше, приложить вот то что вы мне показали.
Только мне кажется «тело» вы привели запроса, а не ответа на него 
Т.е. вы взяли с вкладки headers (Там же в разделе Сеть/Network). А есть еще Response.
И да, sessid и USER_ID- убирайте из ответов, которые здесь публикуете.
Добавлено через 2 минуты
Кстати, для мониторинга достпуности можно пользоваться «Инспектор сайтов» у модуля «Облако Битрикс»
Добавлено через 2 минуты
Так еще уточнение, что то я вашу первую фразу иначе прочитал…
«весом до 5 мб»….. Скажем 1 мб не грузится и меньше?
Тончее я бы даже сказал. меньше 4мб и больше 4 мб. как ведут себя?
Я изначально подумал, у вас больше 5мб грузятся, а меньше нет…
Добавлено через 2 минуты
ой все — теперь освежил начало темы в памяти вы и в ТП битрикс уже обращались ….
Но все же попробуйте уже с предоставлением вот этих «логов» еще раз….
Проблема решена. Поделюсь решением, возможно кому-нибудь пригодится.
Обнаружил в /bitrix/tools/ — .htaccess файл, содержимое:
<Files ~ "^(html_editor_action|mail_entry|upload).php$>
deny from all
</Files>Удалил файл /bitrix/tools/.htaccess и все заработало.
В чистой, оригинальной версии БУС, этого файла нет. Полагаю, был данный файл был добавлен предшественником, для усиления безопасности Битрикс от взломов. Однако вместе с этим был нарушен функционал загрузки картинок через форму создания и редактирования элементов инфоблока.