base bitrix24

Как я настраиваю проект после установки

Сервер настроен, bitrix24 установлен, открываем свою любимую IDE и… нет, не начинаю разрабатывать функционал. Я подготавливаю проект дальше для комфортной работы. Как я это делаю? Сейчас расскажу.

Шаг 1. репозиторий

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

Вводим в корневой директории (www/) команду 

git init

и сразу создаём файл .gitignore, поскольку нам нужно отслеживать далеко не все изменения (например кэш, ядро, загружаемые файлы).

Для начала будет достаточно исключить пару директорий:

/bitrix
/upload

Делаем первый коммит и продолжаем.

Шаг 2. папка local/

Следующий шаг, на мой взгляд, очень важен: создание папки local/. Что это и для чего можно прочитать здесь (официальная документация), коротко скажу, что это директория для хранения собственных разработок и переопределения базовых.

Структура local будет следующая:

- local/
-- js/
-- components/
-- php_interface/
--- classes/
--- console/
--- init.php
--- events.php
--- kernel.php
-- templates
--- .default
---- components

Пробежимся по каждому пункту

Директория js

Служит для хранения собственных js библиотек. Пример создания и использования библиотеки будет рассмотрено в отдельной статье.

Директория components

В эту директорию мы будем помещать собственные компоненты.

Директория templates

Служит для хранения собственных шаблонов и переопределения существующих. В основном эту директорию я использую для расширения и модификации существующих шаблонов компонентов системы. Подробнее ознакомиться со спецификой шаблонов и порядком их поиска системой можно здесь.

Директория php_interface

Системная директория для хранения скриптов позволяющих кастомизировать bitrix24, её содержимому я посвящу отдельную главу.

Шаг 3. local/php_interface

Можно сказать, что эта директория является, если не сердцем, то мозгом проекта.

Файл init.php

Файл инициализации. На многих проектах по какой-то причине этот файл заполнен портянкой всевозможного кода. Это очень сильно усложняет работу и понимание проекта. Я предпочитаю держать этот файл в чистоте и храню в нём код для подключения других файлов. Делаю две вещи.

Первое — это автозагрузка. Позволяет получать доступ к нашим собственным классам, расположенным в директории classes. 

spl_autoload_register(function($sClassName)
{
	$sClassFile = __DIR__.'/classes';

	if ( file_exists($sClassFile.'/'.str_replace('\\', '/', $sClassName).'.php') )
	{
		require_once($sClassFile.'/'.str_replace('\\', '/', $sClassName).'.php');
      	return;
	}

	$arClass = explode('\\', strtolower($sClassName));
	foreach($arClass as $sPath )
	{
	    $sClassFile .= '/'.ucfirst($sPath);
	}
  
	$sClassFile .= '.php';
	if (file_exists($sClassFile))
	{
		require_once($sClassFile);
	}
});

Предположим, что в classes у нас есть директория Aclips, в которой находится Foo.php

namespace Aclips;

class Foo
{
	// ...
}

для получения экземпляра класса мы можем обратиться к нему следующим образом

$testObject = new Aclips\Foo();

Благодаря реализованному методу автозагрузки мы получим то, что хотим.

Второе — подключение нужных мне файлов

foreach( [
	__DIR__.'/kernel.php',
	__DIR__.'/events.php',
	__DIR__.'/vendor/autoload.php',
	]
	as $filePath ) {
	if ( file_exists($filePath) )
	{
		require_once($filePath);
	}
}

Файл kernel.php

Этот файл у меня отвечает за регистрирование служб в сервис локаторе (об этом в другой раз) и за получение переменных окружения.

Некоторые вещи не хочется хранить в системе phone case with strapclick here to find out moreopen link контроля версий (например параметры подключения). Во первых они могут отличаться на тестовом и боевом серверах, во вторых им там просто не место.

Создаём файл .env вне видимости нашего репозитория (например над www) и указываем в нём нужные данные:

param_1=test
param_2=7890
/**
 * Устаревший вариант
 **/

$envFilePath = 'путь к .env файлу';

if (file_exists($envFilePath)) {
    $env = Context::getCurrent()->getEnvironment();

    $iniParams = \parse_ini_file($envFilePath, true, INI_SCANNER_TYPED);

    foreach ($iniParams as $key => $value) {
        $env->set($key, $value);
    }
  
    unset($iniParams);
}
unset($envFilePath);



/**
 * Актуальный вариант
 **/

$envFilePath = 'путь к .env файлу';

if (file_exists($envPath . '/.env')) {
    $env = Main\Context::getCurrent()->getEnvironment();
    $curEnv = $env->getValues();
    $iniParams = \parse_ini_file($envPath . '/.env', true, INI_SCANNER_TYPED);
    
    foreach ($iniParams as $key => $value) {
        $curEnv[$key] = $value;
    }
  
    $env->set($curEnv);
    
    unset($curEnv);
    unset($iniParams);
}

unset($envPath);

Теперь можем получить нужные нам значения

use Bitrix\Main\Context;

$env = Context::getCurrent()->getEnvironment();

$param_1 = $env->get('param_1');
$param_2 = $env->get('param_2');

Вы могли заметить, кто я подключаю файл /vendor/autoload.php, которого не было в структуре папки local/. Это нужно для автозагрузки классов, которые были установлены с помощью composer. Если не планируете его использовать, можете не указывать. А я планирую 🙂

Шаг 4. composer

Здесь нет ничего сложного, просто устанавливаем composer и выполняем в директории php_interface команду, если не хотим создавать файл composer.json вручную

composer init

Я предпочитаю не вносить пакеты, установленные через composer в .gitignore, так как некоторые серверы могут быть изолированы от внешней сети и мы не сможем установить все требуемые пакеты и зависимости.

На этом базовую настройку проекта можно считать законнченой и можно приступать к работе.

Добавить комментарий