Файл ошибки существует восстановить php

«1С-Битрикс: Управление сайтом» — одна из самых популярных коммерческих CMS. Как и в случае с любой другой CMS, при работе с Битриксом возникают разные ошибки, мешающие нормальной работе сайта. Выявить их можно с помощью встроенного функционала проверки системы в панели администратора Битрикс.

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

  1. Ошибка «The script encountered an error and will be aborted. To view extended error messages, enable this feature in .settings.php.» при переходе на сайт
  2. «Замечание. Агенты выполняются на хитах, рекомендуется перевести выполнение агентов на cron» при проверке системы 
  3. Ошибка работы с сокетами при проверке системы
  4. Ошибка! Не работает «Отправка почты» и «Отправка почтового сообщения больше 64Кб» при проверке системы
  5. «Служебные скрипты в корне сайта. Ошибка! Файл существует» при проверке системы
  6. Ошибка «Загрузка файла» и «Загрузка файла больше 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
— ее лучше закомментировать.

Ошибка работы с сокетами при проверке системы

При проверке системы в панели администратора Битрикс может возникнуть ошибка «Работа с сокетами. Ошибка! Не работает».

Также из-за ошибки работы с сокетами другие тесты проводятся некорректно, выдавая ошибку «Замечание. Не удалось проверить из-за ошибки в работе с сокетами».

Если А-записи указаны корректно, возможно в файле /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 или к разработчику модуля отправки почты.

Если письмо не пришло, а вы получили уведомление «Отправка не удалась» — необходимо более детальное изучение проблемы. В таком случае потребуется вмешательство системного администратора.

«Служебные скрипты в корне сайта. Ошибка! Файл существует» при проверке системы

Такая ошибка говорит о наличии в корне сайта служебных скриптов, например, restore.php
. Данные скрипты, как правило, добавляют временно для проведения каких-либо работ (например, restore.php
— для восстановления сайта из резервной копии). Так или иначе, после выполнения работ такие скрипты необходимо удалить с сервера, так как они представляют угрозу безопасности сайту и данным.

Ошибка «Загрузка файла» и «Загрузка файла больше 4Мб» при проверке системы

Проверка системы Битрикс загружает файл размером более 4Мб. В большинстве случаев такая ошибка говорит об ограничениях в параметре upload_max_filesize
для PHP.

Необходимо в файле конфигурации PHP установить данное значение выше 4Мб и перезапустить веб-сервер. В зависимости от окружения файл конфигурации PHP может находится в разных местах. Обычно данное значение устанавливается в файле /etc/php.ini
.

Если вы используете панель ISPmanager — поправить конфигурацию можно прямо в ней: выберите нужный сайт, нажмите на кнопку PHP
в верхней панели, найдите параметр upload_max_filesize
и укажите нужное значение. Если вы используете окружение BitrixVM, необходимо вносить изменения в специальные файлы конфигурации, чтобы после перезагрузки сервера они не вернулись в исходное состояние. Подробнее можете узнать по ссылке.

Дело в том, что в стандартном компоненте обновлений Joomla используются скрипты компании Akeeba. И Joomla и Akeeba выпустили свои обновления, закрывающие данную уязвимость, однако они не посчитали это критической уязвимостью и поэтому очень многие не обратили на это особого внимания.

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

Как это работает:

Но есть одно огромное НО. Если в процессе обновления возникла ошибка (что довольно часто случается), то файл restoration.php не удаляется, а продолжает находиться рядом с файлом restore.php. И ваш сайт превращается в полное решето, теперь хакер может заливать шелл когда угодно.

Про ГИС ЖКХ:  Экономьте деньги: найдите лучшие предложения, платя меньше

Если вам необходима помощь — вы в любой момент можете обратиться к нашим специалистам.

3 уровень
— средняя сложность. Необходимо внимание и немного подумать.

  Перенос сайта нештатными средствами

Перенос сайта на хостинг лучше всего выполнять встроенными в Bitrix Framework
средствами резервного копирования/восстановления.

Несмотря на то, что фактически сайт на «1С-Битрикс: Управление сайтом»
представляет из себя набор файлов и базу данных, копирование файлов напрямую на удаленный сервер в большинстве случаев будет не верным решением. Из-за большого количества мелких файлов такое копирование может растянуться на несколько часов. Кроме того, использование стандартных механизмов позволяет избежать последующих возможных проблем с правами доступа к файлам сайта.

Среди часто возникающих проблем:

  1. Веб-сервер не может записать в нужную ему папку или удалить временные файлы. Возможные последствия:
    • невозможность обновления продукта;
    • невозможность редактировать сайт через веб-интерфейс;
    • некорректная работа компонента кэширования;
    • и другие проблемы.

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

      Самым простым решением в этом случае будет установка прав на все файлы и папки 777 (для Unix
      платформы) либо любой другой способ дать PHP запись на эти файлы.

  2. Нет возможности отредактировать через ftp/ssh файлы, созданные через веб-интерфейс. В этом случае многим веб-разработчикам будет сложно дорабатывать сайт.

    Одним из простых, но не всегда работающих решений, является установка параметров в файле dbconn.php
    , позволяющих всем редактировать создаваемые через Bitrix Framework
    файлы.

     define("BX_FILE_PERMISSIONS", 0666);
    define("BX_DIR_PERMISSIONS", 0777); 

    Однако для файлов, созданных через ftp/ssh, вам придется периодически изменять права вручную. Либо, если хостинг это поддерживает, устанавливать параметр umask
    .

  Настройки PHP

При переносе сайта на хостинг могут возникнуть различные нюансы из-за настроек PHP:

  • Проблемы с несоответствием владельца файлов: на ряде хостингов PHP работает от имени одного пользователя, а доступ по ftp/ssh предоставлен другому. В этом случае файлы, созданные одним методом, могут быть недоступны для модификации, или вообще вызывать ошибку выполнения из-за нарушения параметров безопасности.
  • Проблемы с настройками безопасности: возможны различные варианты подключения PHP к веб-серверу, и в некоторых из этих вариантов устанавливаются жесткие ограничения на владельца файла и права на файл. В этом случае возможны ошибки с кодом 500, и разобраться в проблеме вам поможет только журнал ошибок веб-сервера.

    Пример
    : На многих хостингах, если PHP подключен как CGI, требуется соответствие владельца файла и прав на файл. Если владелец файла – не ваш аккаунт или права на файл допускают запись всем пользователям, PHP будет вызывать ошибку. В этом случае необходимо установить корректные права на файлы и папки, а также правильные параметры в dbconn.php
    .

  • Ограничения на время выполнения скрипта или на другие выделяемые ресурсы. В этом случае сайт может вести себя странно – то открываться, то не открываться и показывать белый экран.

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

  • Другие проблемы, специфичные для вашего хостера. Для их устранения рекомендуем заранее протестировать работу сайта на выбранном вами хостинге и заручиться контактами специалистов службы поддержки провайдера.

  Возможные проблемы при работе с многосайтовостью в Bitrix Framework

Проверьте, что ваш хостинг позволит организовать многосайтовость выбранным вами методом. Не все провайдеры позволяют корректно (для Bitrix Framework
) создавать дополнительные сайты. Информацию об способах организации многосайтовости можно получить в учебном курсе Многосайтовость.

Проблемы с почтой

Некоторые хостинги не позволяют отправлять почту без авторизации. В этом случае для отправки письма с сайта вам необходимо будет переопределять функцию отправки почту в соответствии с документацией к продукту.

Распакованный сайт недоступен

После распаковки резервной копии на всём сайте отображается только форма авторизации. Возможные причины и решения:

  • Некорректное значение поля Путь к корневой папке веб-сервера для этого сайта
    в настройках сайтов ( Настройки > Настройки продукта > Сайты > Список сайтов
    ).

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

  • Если перенос осуществлялся простым копированием файлов (FTP/SSH)
    , мог не скопироваться файл .access.php
    . В данном файле хранятся права доступа групп пользователей к сайту, если данного файла нет, то для всех пользователей устанавливается право Запрещено
    .

    Решение 1
    : в корень сайта положить файл .access.php
    с содержимым:

     <? $PERM["/"]["*"]="R"; ?> 

    Решение 2
    : через файловый менеджер продукта в свойствах корневой папки сайта на вкладке Доступ
    установить для группы Все пользователи (в том числе неавторизованные)
    право Чтение
    .

Про ГИС ЖКХ:  Оптимизируйте муниципальные операции с помощью нашей службы заказов

Не полный архив

При просмотре архива, созданного штатной системой резервного копирования, через WinRar видно, что файлов в архиве гораздо меньше, чем на сайте.

Причина: дело в том, что у формата tar
есть несколько диалектов. Система пакует архив в формате GNU tar
, как это делает по умолчанию tar
в Linux
. WinRar понимает tar
, но конкретно этот диалект поддерживает не полностью.

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

Ошибка ERROR 1062 (23000)

При распаковке резервной копии происходит ошибка: ERROR 1062 (23000) at line 1247: Duplicate entry '2-?' for key 2
.

Причина: Ошибка происходит, если кодировка, в которой сделан архив, отличается от используемой на новом сервере баз данных.

  • Кодировка архива устанавливается в зависимости от содержимого файла /bitrix/php_interface/after_connect.php
    , например:
     <?
    $DB->Query("SET NAMES 'utf8'");
    ?> 

    т.е архив будет создаваться в кодировке utf8
    .

  • Кодировку сервера баз данных можно увидеть в параметре character_set_server
    после выполнения SQL-запроса:
     show variables where Variable_name = 'character_set_server'; 

Обойти или устранить эту ошибку можно двумя способами:

  • В настройках нового сервера баз данных изменить кодировку в параметре character_set_server
    на ту, в которой сделан архив.

    Внимание!
    За выполнением этой операции возможно придется обратиться к администратору сервера.

  • Можно открыть архив в текстовом редакторе и в самое начало вставить строку:
     SET NAMES `utf8`; 

    Кодировка выбирается в зависимости от кодировки архива.

    Внимание!
    Этот способ работает только в случае небольших дампов (которые успевают импортировать за один шаг).

Ошибки в .htaссess

Часть ошибок (например: ошибка 404 при переходе подробную информацию новостей), возникающих при переносе сайтов связана с тем, что при переносе файл .htaссess
переименовывается с добавлением «_». Для решения проблемы достаточно проверить имя файла и, при обнаружении ошибки, восстановить его.

HTTP Error 500 при установке через restore.php

Пытаюсь установить Битрикс на хостинге и получаю в браузере ошибку HTTP Error 500
. Панель управления хостингом FastPanel, VPS. Все по-умолчанию, никаких кастомных конфигураций не делал.

Файл ошибки существует восстановить php

Решение:

Переключить в хостинг панели версию PHP на более новую версию (в данном случае переключил с php54 на php74) и всё заработало.

Файл ошибки существует восстановить php

Файл ошибки существует восстановить php

Автор проекта: Dimos

Заметки программиста, дизайнера, геймдев-мастера.

Делюсь опытом.

код файла .htaccess:

 Options -Indexes
ErrorDocument 404 /404.php
<IfModule mod_php5.c> php_flag session.use_trans_sid off #php_flag default_charset UTF-8 #php_value display_errors 1
</IfModule>
<IfModule mod_php7.c> php_flag session.use_trans_sid off #php_flag default_charset UTF-8 #php_value display_errors 1
</IfModule>
<IfModule mod_rewrite.c> Options +FollowSymLinks RewriteEngine On	# ASPRO_ROBOTS Serve robots.txt with robots.php only if the latter exists	RewriteCond %{REQUEST_FILENAME} robots.txt	RewriteCond %{DOCUMENT_ROOT}/robots.php -f	RewriteRule ^(.*)$ /robots.php [L] RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-l RewriteCond %{REQUEST_FILENAME} !-d RewriteCond %{REQUEST_FILENAME} !/bitrix/urlrewrite.php$ RewriteRule ^(.*)$ /bitrix/urlrewrite.php [L] RewriteRule .* - [E=REMOTE_USER:%{HTTP:Authorization}]
</IfModule>
<IfModule mod_dir.c> DirectoryIndex index.php index.html
</IfModule>
<IfModule mod_expires.c> ExpiresActive on ExpiresByType image/jpeg "access plus 3 day" ExpiresByType image/gif "access plus 3 day" ExpiresByType image/png "access plus 3 day" ExpiresByType text/css "access plus 3 day" ExpiresByType application/javascript "access plus 3 day"
</IfModule> 

Если вы еще не восстанавливали/переносили Битрикс на свеженький (или не очень) сервер с PHP 7, то вы счастливый человек. Нет, сам Битрикс на PHP 7 работает более чем хорошо, я бы даже сказал, что намного лучше, чем на 5. X.

Т.е. все прекрасно, кроме самого процесса переноса. Если вы воспользуетесь официальным инструментом от Битрикса – скриптом restore.php, то столкнетесь с проблемами. Собственно, как только дело дойдет до восстановления базы данных – сервер упадает в 500 ошибку, а в логах появится следующая запись:

Решение тут понятно простое – восстановить базу руками, что, понятно, несложно. Нет один, два раза без проблем, но на десятый уже конечно надоедает.

Собственно решение тут одно, взять и поправить код скрипта, благо правок так немного. Что и было сделано:

  • Убран код, который скачивает свежую версию скрипта с Битрикса и подменяет текущий файл;
  • Собственно все старые не поддерживаемые функции заменены на аналоги из mysqli

Как только в Битрикс выпустят свою нормальную версию – ссылку заменю на официальный продукт.

Upd: Вышел официальный restore.php с поддержкой mysqli.

При попытке запустить битрикс файл restore.php получаю ошибку Internal Server Error The server encountered an internal error or misconfiguration and was unable to complete your request.

Первоначально ошибку связывал с тем, что сайт был создан в однобайтовой кодировке, а файл restore.php был в кодировке UTF-8

В результате сервер не мог обработать запрос. После смены кодировки файла restore.php на WINDOWS-1251 проблема не была решена.

В итоге выяснилось, что домен был направлен на другой чужой аккаунт этого же хостинга и для привязки домена к моей услуге хостинга, нужно подтвердить владение им, написав заявку в тех. поддержку с контактного email владельца домена.

.

500 Internal Server Error.png



Оцените статью
ГИС ЖКХ