Довольно часто есть желание что-то быстро поправить в произвольном файле продукта через встроенный файловый менеджер. И досадно, когда секундное редактирование может окончиться сбоем в работе какой-то публичной страницы, а ещё хуже - ядра. В связи с этим сделал просто скрипт, который проверяет файл на корректность перед сохранением:
<?
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");
Теперь при ошибке в коде получаем подобные сообщения: файл не сохранится, пока ошибка не будет исправлена.
P.S. Только не сильно увлекайтесь правками ядра P.S.S. Спасибо за идею
Изначально не предполагал, что будете править компоненты.В Вашем случае можно вторую команду не выполнять, ограничившись только синтаксической проверкой файла.
Доброго времени суток. С момента выхода модуля "Веб кластер" стала актуальна задача выноса таблиц произвольного модуля в отдельную базу данных. Делается это по разным причинам, главные из которых повышение производительности и стабильности проекта в целом.
Всё делается в несколько этапов:
Модифицируем файл /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С-Битрикс».
Группы на сайте создаются не только сотрудниками «1С-Битрикс», но и партнерами компании. Поэтому мнения участников групп могут не совпадать с позицией компании «1С-Битрикс».
if(!defined("B_PROLOG_INCLUDED") || B_PROLOG_INCLUDED!==true) die();