Довольно часто есть желание что-то быстро поправить в произвольном файле продукта через встроенный файловый менеджер. И досадно, когда секундное редактирование может окончиться сбоем в работе какой-то публичной страницы, а ещё хуже - ядра. В связи с этим сделал просто скрипт, который проверяет файл на корректность перед сохранением:
<?
AddEventHandler("main", "OnBeforeChangeFile", "OnBeforeChangeFileHandle");
function OnBeforeChangeFileHandle($abs_path, $strContent)
{
define("PATH_TO_PHP", "/usr/bin/php");
// Для веб окружения путь к PHP будет следующим
//define("PATH_TO_PHP", "C:\Program Files (x86)\Bitrix Environment\apache2\zendserver\bin\php.exe");
if (substr($abs_path, strlen($abs_path)-3, 3) == "php")
{
$tmpPath = $_SERVER["DOCUMENT_ROOT"].BX_PERSONAL_ROOT."/cache/".substr(md5(time()), 0,3)."_".basename($abs_path);
if (file_exists($tmpPath ))
unlink ($tmpPath);
$f = fopen($tmpPath, "a+");
if ($f)
{
$tmpProlog = '<?php $_SERVER["DOCUMENT_ROOT"] = "'.$_SERVER["DOCUMENT_ROOT"].'"; ?>';
fwrite($f, $tmpProlog);
fwrite($f, $strContent);
fclose($f);
//syntax analyse
$parse_error = "";
$command1 = '"'.PATH_TO_PHP.'" -l "'.$tmpPath.'"';
ex ec($command1, $text1, $errNum1);
if (!($errNum1 === 0 && is_array($text1) && strpos($text1[0], "No syntax errors detected") === 0))
{
unlink ($tmpPath);
$GLOBALS['APPLICATION']->ThrowException($text1[1]);
return false;
}
$command2 = '"'.PATH_TO_PHP.'" -f "'.$tmpPath.'"';
$fatal_error = ex ec($command2, $text2, $errNum2);
if ($fatal_error !== "" && strpos($fatal_error, "on line") !== false)
{
unlink ($tmpPath);
$GLOBALS['APPLICATION']->ThrowException($fatal_error);
return false;
}
unlink ($tmpPath);
}
}
return true;
}
?>
осталось только указать путь к PHP:
define("PATH_TO_PHP", "/usr/bin/php");
Теперь при ошибке в коде получаем подобные сообщения: файл не сохранится, пока ошибка не будет исправлена.
Изначально не предполагал, что будете править компоненты.В Вашем случае можно вторую команду не выполнять, ограничившись только синтаксической проверкой файла.
Доброго времени суток. С момента выхода модуля "Веб кластер" стала актуальна задача выноса таблиц произвольного модуля в отдельную базу данных. Делается это по разным причинам, главные из которых повышение производительности и стабильности проекта в целом.
Всё делается в несколько этапов:
Модифицируем файл /bitrix/modules/<название_модуля>/install/index.php В метод InstallDB() добавляем строку:
Т.е. мы говорим модулю "Веб кластер", что у нас есть модуль "Задачи", для примера, который может хранить свои таблицы в отдельной БД, перечисляем эти таблицы.
2. Модификация файла /bitrix/modules/<название_модуля>/include.phpВ список классов для autoload добавляем класс инсталлятора модуля:
Недавно на форуме встретил интересную задачу клиента: при переводе результата заполнения веб формы в определённый статус создавать событие в календаре событий компании.
Задачу решал с помощью обработчиков, стараясь сделать код максимально универсальным. Где этого сделать не удавалось - вставлял константы. Принцип работы такой: 1. В символьный код веб формы добавляем произвольный набор символов (FORM_SID), не обязательно SID формы должен совпадать со значением константы FORM_SID.
2. Теперь после создания нового результата в веб форме с определённым SID будет создан новый статус с названием STATUS_TITLE.
3. Редактор сайта "проверяет" результат заполнения, переводит его в новый статус, в нашем случае "в календарь".
4. После этого в календаре событий компании (с ID, указанным в IBLOCK_CALENDAR) создаётся новый подкалендарь с названием CALENDAR_NAME.
5. Название и время события берутся из ответов на вопросы веб формы - FORM_FIELD_NAME и FORM_FIELD_DATE соответственно.
Сотрудники тех. поддержки часто испытывают проблему с долгим поиском по большому числу старых обращений, поступивших в ТП (например хочется найти свой ответ на какую-либо типовую проблему или что-то в этом духе). Модуль support формирует довольно тяжелые запросы, из-за большого количества записей в БД, фильтров и сортировок, выполнение этих запросов сказывается на общей производительности сайта.
Считаю, что оптимальным решением проблемы будет переложить задачу поиска с модуля "Тех. поддержка" на модуль "Поиск". Обусловлено это тем, что поиск будет идти всегда по индексам, доступен морфологический разбор, логика при поиске и другие вкусности.
Решать задачу будет следующий код (вставляем в init.php):
Задача решается обработкой события OnReindex модуля "Поиск" и относительно новых событий OnAfterTicketAdd, OnAfterTicketUpdate, OnTicketDelete модуля "Тех. поддержка".
Думаю каждый для себя определит, куда должна вести ссылка на обращение с компонента поиска.
function OnAfterTicketAddHandler (&$fields)
{
if ($fields["ID"] == "")
$fields["ID"] = $_POST["ID"];
Узнал, что в событие OnAfterTicketUpdate не передаётся ни ID добавленного сообщения, ни ID текущего обращения, поэтому пришлось вставить небольшой хак, который имеет право на жизнь на стандартных компонентах и в админке.
Вроде всё:
Всем пока.
UPD. Событие OnReindex вызывается также и при переиндексации сайта, т.е. можно всегда держать базу обращений в актуальном состоянии.
Сотрудники тех. поддержки часто испытывают проблему с долгим поиском по большому числу старых обращений, поступивших в ТП (например хочется найти свой ответ на какую-либо типовую проблему или что-то в этом духе). Модуль support формирует довольно тяжелые запросы, из-за большого количества записей в БД, фильтров и сортировок, выполнение этих запросов сказывается на общей производительности сайта.
Считаю, что оптимальным решением проблемы будет переложить задачу поиска с модуля "Тех. поддержка" на модуль "Поиск". Обусловлено это тем, что поиск будет идти всегда по индексам, доступен морфологический разбор, логика при поиске и другие вкусности.
Решать задачу будет следующий код (вставляем в init.php):
Задача решается обработкой события OnReindex модуля "Поиск" и относительно новых событий OnAfterTicketAdd, OnAfterTicketUpdate, OnTicketDelete модуля "Тех. поддержка".
Думаю каждый для себя определит, куда должна вести ссылка на обращение с компонента поиска.
function OnAfterTicketAddHandler (&$fields)
{
if ($fields["ID"] == "")
$fields["ID"] = $_POST["ID"];
Узнал, что в событие OnAfterTicketUpdate не передаётся ни ID добавленного сообщения, ни ID текущего обращения, поэтому пришлось вставить небольшой хак, который имеет право на жизнь на стандартных компонентах и в админке.
Вроде всё:
Всем пока.
UPD. Событие OnReindex вызывается также и при переиндексации сайта, т.е. можно всегда держать базу обращений в актуальном состоянии.
Группы на сайте создаются не только сотрудниками «1С-Битрикс», но и партнерами компании. Поэтому мнения участников групп могут не совпадать с позицией компании «1С-Битрикс».