php

Выводим в header.php компонент с параметрами переданными в теле странцы

Итак чтобы не забывать и постоянно не вспоминать как это делается запишу.
Нам нужно в хидере вывести какую либо информацию, но не просто вставить компонент в шаблон, а передавать в этот компонент какие-то параметры которые мы получаем только в теле страницы.

Делается это так. Пишется функция вида

function componentHeader($text)
{
	global $APPLICATION;
	$arParams = $APPLICATION->GetPageProperty('PARAMS');
	if(is_array($arParams))
	{
		ob_start();
			$APPLICATION->IncludeComponent('demo:test', '', $arParams);
			$contentTime = ob_get_contents();
		ob_end_clean();
		return $contentTime;
	}
}

кладем ее как через init.php и в хидере выводим $APPLICATION->AddBufferContent(«componentHeader»); должно работать.

Мини GetList для файлов

В исходниках битрикса есть CAllFile::GetList($arOrder, $arFilter, $arParams); но он видимо служит для внутреннего использования и не описан в документации. Нам нужно выбрать описание по 10 файлам за раз, этот метод, в качестве параметра фильтра массив из ID файлов не принял. Пришлось накидать свою функцию.

function __arfileGetList($ar_FileID)
{
	if(is_array($ar_FileID) && count($ar_FileID) > 0)
	{
		global $DB;
		$rs_File = $DB->Query(
			"SELECT * FROM b_file WHERE ID IN 
                               (". implode(',', $ar_FileID). ")",
			false,
			"FILE: ".__FILE__." LINE: ".__LINE__
		);
		while($ar_File = $rs_File->Fetch())
		{
			$ar_Result[] = $ar_File;
		}

		if(is_array($ar_Result) && count($ar_Result) > 0)
			return $ar_Result;
	}
}

P/S
Не забудте проверить $ar_FileID, чтобы там были именно ID файлов…

Битрикс и большой кэш по ID

Итак представим что у вас или у вашего клиента большой, высоко-посещаемый сайт. Также представим инфоблок в котором больше 80k элементов. Наверняка у этих элементов есть детальное описание  и я уверен 99,9% что ID кэша это ID вашего элемента.

Итак у нас получается что в папке допустим /bitrix/cache/object_80k/ — 80 000 папок с кэшем, т.е.

/bitrix/catche/object_80k/1

/bitrix/catche/object_80k/2

/bitrix/catche/object_80k/3

/bitrix/catche/object_80k/n

/bitrix/catche/object_80k/80 000

Какой бы у вас не был сервер, поиск папки в общем списке из 80k занимает время. Плюс если сайт посещаемый то вы догадываетесь что происходит, нагрузка на ровном месте, даже я бы сказал в том месте где мы пытаемся ее уменьшить.

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

function __getGenerationCachePath($id)
{
    $hash = md5($id);
    $path = substr($hash,-4,2).'/'.substr($hash,-2);
    return $path;
}

Пример:

$ob_Cache     = new CPHPCache;
$i_CacheTime  = 3600;
$s_CacheID    = $ID;
$s_CachePatch = "/object_80k/" . __getGenerationCachePath($ID) . "/" . $ID . "/";
if($ob_Cache->InitCache($i_CacheTime, $s_CacheID, $s_CachePatch))
{
    $ar_Cache  = $ob_Cache->GetVars();
    $ar_Result = $ar_Cache['ITEAM'];
}
else
{
    $ar = ''; // выборка
    if($obCityCache->StartDataCache())
    {
        $obCityCache->EndDataCache(array('ITEAM' => $ar));
    }
}

Итак функция создаст путь вида /object_80k/as/df/ID и тем самым разобьет 80k папок на под папки, тем самым уменьшит время поиска кэша и общую нагрузку на сервер.

Да и еще важный момент, функция написана с учетом что ID > 100 000k. хотя тем кому это пригодится это не важно…

str_replace, если работаем с массивами

Сегодня заметил небольшую особенность в стандартной php функции, которую раньше как-то не замечал. Вылез баг в замене значения по маске через  str_replace. Код выглядит вот так :

    $ar_ResultList[] = str_replace(
	array("#ID#", "", "", "", "#CODE#", 
"#CITY_CODE#", "#DETAIL_URL#", "#HOTEL_CODE#"),
	$ar_ObjectFiled,
	$s_LinkTemplates
   );

Это уже исправленный код, т.е если мы ищем и заменяем в массиве то ключи должны совпадать и по расположению, т.е. по ключам.

Класс для сортировки массива, usort [php]

Пример реализации выборки из нескольких инфоблоков с постраничной навигацией и сортировкой.

Задача:

1) Выбрать список элементов из нескольких инфоблоков в таблицу;

2) Иметь возможность сортировки элементов;

3) Должна работать постраничная навигация

Итак этот пример можно использовать при небольшом кол-ве выбираемых элементов, думаю максимум до 100, естественно с кэшированием.

Первым делом нужно выбрать все данные в ассоциативный массив, например вот такой:

 [ITEAM] => Array
        (
            [0] => Array
                (
                    [CITY_NAME] => value
                    [CITY_DETAIL_URL] => value
                    [OBJECT_NAME] => value
                    [OBJECT_ID] => 2487
                    [DATE_CREATE] => 02.07.2006
                    [STATUS] => Y
                    [PAID_STATUS] => Y
                    [DATEIL_OBJECT_URL] => value
                )

            [1] => Array
                (
                    [CITY_NAME] => value
                    [CITY_DETAIL_URL] => value
                    [OBJECT_NAME] => value
                    [OBJECT_ID] => 2489
                    [DATE_CREATE] => 02.07.2006
                    [STATUS] => Y
                    [PAID_STATUS] => N
                    [DATEIL_OBJECT_URL] => value
                )

Continue reading

Инфоблоки +, события [bitrix api]

Хочу предостеречь от очень каверзной особенности работы с расширенными инфоблоками у Битрикса, так называемыми Инфоблоками +.

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

Это происходит только на инфоблоках + и не с включенным документооборотом для этого инфоблока. Все дело в массиве PROPERTY_VALUES, в котором вы меняете значение какого-то свойства. Подвох в том что вы не используете метод $el->Update($ID, $arParams) в самом обработчике, и это ошибка трудно уловима, по сути обработчик переопределяет   $arParams[‘PROPERTY_VALUES’], по этому в нем будет только ваше изменение из обработчика. В этом случае, если вы будете использовать $el->Update($ID, $arParams) к этому инфоблоку в другом месте, свойства будут сбрасываться.

События хорошая штука, но нужно внимательнее сними работать, ими не стоит злоупотреблять.

Битрикс ЧПУ, готовим символьный код элемента [bitrix api]

Итак вот вам маленький пример, снипет, как можно легко подготавливать добавляемые элементы для поддержки ЧПУ в Битриксе.

Вообще считаю что это должно быть по умолчанию. Т.е. выставляться в настройках инфоблока просто галочкой, так как это займет для разработчиков БУС примерно 1 час.

Пока этого нет, будем делать сами. Итак сейчас в стандартном функционале множества компонент добавили ЧПУ по полю CODE элемента. Это хорошее поле и удобно с ним работать, да и именно для этого оно видимо и предназначено, хотя можно использовать и просто свойства да и пользовательские свойства тоже.

Итак задача :

1. Нужно название элемента переводить в траслит и добавлять его в поле CODE.

2. Это нужно делать автоматически.
Continue reading

Правильное удаление элементов [bitrix api]

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

После чего ему нужно всего навсего добавить картинку, например на форум, и в адрес url картинки подставить определенно сформированный адрес.

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

www.site.ru/news/detail.php?ID=777&del=Y

Теперь если мы добавим пост на форум или блоги, и добави картинку с ссылкой,

<img src=»www.site.ru/news/detail.php?ID=777&del=Y» />

то администратор будучи авторизованным благополучно удалить элемент в ID 777. Проблема думаю ясна, теперь как это предотвратить.

Continue reading