вторник, 19 февраля 2013 г.

Как развернуть несколько сайтов в локали в Битрикс Веб-окружении

Казалось бы, избитая тема, но меня часто спрашивают, как сделать это, поэтому решила написать.
Ищем файл default.conf
у меня он лежит в
C:\Bitrix\apache2\conf\sites
у других может лежать в другом месте, в зависимости от версии Битрикс Веб-окружения и от того, куда она установлена - суть от этого не меняется.

В нем по-умолчанию прописан только один виртуальный хост

#Bitrix Env replace()
Listen 6448
<VirtualHost _default_:6448>
DocumentRoot "C:/Bitrix/www"
ErrorLog "logs/default-error.log"
CustomLog "logs/default-access.log" common
</VirtualHost>
#/Bitrix Env replace()

Но можно прописать сколько угодно дополнительных, например так:

#Bitrix Env replace()
Listen 6448
<VirtualHost _default_:6448>
DocumentRoot "C:/Bitrix/www"
ErrorLog "logs/default-error.log"
CustomLog "logs/default-access.log" common
</VirtualHost>
Listen 6449
<VirtualHost _default_:6449>
DocumentRoot "
C:/папка, в которой будут лежать файлы другого сайта/"
ErrorLog "logs/default-error.log"
CustomLog "logs/default-access.log" common
</VirtualHost>
#/Bitrix Env replace()

Записали, сохранили, перезапустили Веб-окружение, и теперь по адресу http://localhost:6448 будет открываться один сайт, а по адресу http://localhost:6449 - другой

Git обновить текущую ветку из master

Если разработка велась в ветке, и за время этой разработки ветка master сильно изменилась, лучше не вливать ветку сразу в мастер, а сначала влить мастер в ветку – чтобы предварительно протестировать.
Для этого нужно переключиться на ту ветку, в которую мы будем вливать мастер, а затем выполнить команду
git pull origin master
Cкорее всего, после этого возникнут конфликты – гит скажет об этом.
Чтобы просмотреть все файлы, в которых произошли конфликты, нужно выполнить команду
git status
После разрешения конфликтов, нужно сделать коммит, а потом снова выполнить
git pull origin master
Таким же образом можно периодически вливать в ветку новые изменения из мастера, если нужно, чтобы ветка не сильно «отошла» от основной версии проекта.

суббота, 2 февраля 2013 г.

Кастомизация экспорта заказов в 1С Предприятие без модификаций ядра 1С Битрикс

Продолжая тему нестандартной интеграции 1С Битрикс и 1С Предприятия, хочу рассказать о том, как я кастомизирую экспорт заказов. Это тоже довольно востребованная и распространённая задача, и, что интересно, практически всегда заказчиков не устраивает экспорт «из коробки», и они просят пусть какие-то мелочи, но переделать.

Например, недавно я столкнулась с такой задачей. Оптовые покупатели интернет-магазина (на 1С Битрикс Бизнес 11й версии ядра) обладают дополнительными свойствами: номерами договоров и датами заключения этих договоров. При оформлении заказа они выбирают один из своих договоров, на основании которого будет происходить сделка. Номер договора и его дата – должны передаваться в 1С предприятие при экспорте заказов.

Формированием xml-файла заказов, который передается в 1С Предприятие, занимается функция из ядра Битрикс ExportOrders2Xml, которая описана в файле bitrix/modules/sale/general/export.php

Конечно, соблазн исправить пару строк в ней прямо там на месте – велик. Это займет 5 минут. НО ядро битрикс станет модифицированным и каждый раз, обновляя ядро, нужно будет помнить об этой модификации и вносить ее снова. Каждый раз. А если проект перейдет на сопровождение другой студии или разработчику (как частенько бывает), и заказчик забудет о том, что ядро его проекта модифицировано, в один прекрасный день это может обернуться серьезными проблемами. Поэтому, я думаю, что лучше сразу потратить 30 минут вместо 5, но кастомизировать экспорт так, чтобы ядро не было затронуто, и чтобы об этой модификации не нужно было помнить.

Как я делаю? Я копирую компонент sale.export.1c  из папки /bitrix/components/bitrix/ в свое пространство имен /bitrix/components/bedrosova/, затем в папке компонента создаю еще 1 файлик /bitrix/components/bedrosova/sale.export.1c/functions.php

В этот файлик я копирую полное описание функции ExportOrders2Xml из файла bitrix/modules/sale/general/export.php  и незамысловато переименовываю ее в ExportOrders2Xml2 (а здесь нужно отметить, что исходная функция ExportOrders2Xml – это статический метод класса, и именно поэтому описываемый мною способ применим. Если бы этот метод не был статическим, то пришлось бы либо копировать весь класс, содержащий его, либо заводить класс – наследующий его. Наследование – это, конечно, спорный механизм, но не в сравнении с модификацией исходного класса) и затем уже в своей скопированной функции вношу все необходимые мне модификации.

После этого я подключаю файл со своей функцией
 /bitrix/components/bedrosova/sale.export.1c/functions.php
 в своем компоненте /bitrix/components/bedrosova/sale.export.1c/components.php 

Затем заменю вызов статического метода класса
CSaleExport::ExportOrders2Xml на вызов свой функции ExportOrders2Xml2

Все, остается только не забыть заменить в файле обмена вызов стандартного компонента sale.export.1c   на вызов кастомизированного.

Кастомизация экспорта заказов описанным методом не слетает даже при переходе с 11й версии ядра на 12ю, в которой стандартный экспорт организован с использованием класса CIBlockCMLExport. О его кастомизации без модификации ядра я напишу как-нибудь в другой раз.