Доброго времени суток ) Решил таки опубликовать модуль для подключения доктрины к битриксу - ссылка на , инструкция по установке и использованию там же.
Пара слов зачем это нужно и кому может пригодиться. Я с этим модулем делал два крупных проекта, сейчас делаю сайт турфирмы - в базе на текущий момент уже 12 таблиц со сложными связями, которые невозможно реализовать на инфоблоках, а orm битрикса сильно проигрывает по удобству и функционалу doctrine orm.
Мокрушин Алексей, сперва бы доделать там на самом деле очень много надо сделать, а времени нет. Хотя бы доделать апи для связки elasticsearch и битрикса (добавление в индекс и получение из индекса). После этого уже можно говорить о каких-то компонентах и модулях. И то, это всё очень специфично. А в битриксе сейчас появились фасеты, поэтому уже часть задачи отпало. Хотя с elasticsearch можно забабахать офигенный поиск с ранжированием и фильтрацией.
Гаврилов Евгений, там отличный дашбоард на Кибане можно замутить. И это же практически рилтайм отображение характеристик. Ко всему прочему ту же Кибану можно и под отображение разных моментов приспособить
Используем PhpStorm для разработки На текущий момент есть много замечательных IDE с поддержкой PHP/JS/HTML, но я с давних пор пользуюсь
Далее - подробная инструкция как начать работу с этой замечательной IDE.
Рассмотрим самый простой вариант - битрикс уже развернут на хостинге, есть ftp/sftp доступ. Создаем новый проект: Выбираем создание проекта из исходников, доступных по ftp: Задаем название проекта, папку, где будет находиться проект и обязательно выбираем "custom": В дополнительных настройках много пунктов, нам потребуется изменить следующие: "Upload changed files automatically to the default server" - "Always" - загружать измененные файлы на сервер "warn when uploading over newer file" - "Compare content" и "Notify about remote changes" - полезно, если над проектом работает больше одного разработчика - phpstorm будет предупреждать об изменениях файлов на сервере, это поможет избежать перезаписи изменений друг друга.
Настраиваем параметры соединения:
Далее - необходимо указать корневую папку сайта на сервере (Project root) и исключить все остальные папки(или по крайней мере папку bitrix. Иначе скачивание проекта может занять несколько часов, проще это позже сделать в фоновом режиме).
Открываем в правой части экрана вкладку "Remote Host" и заходим в настройки (иконка с тремя точками рядом с названием подключения). Во вкладке "Excluded path" удаляем из исключений все локальные папки
Теперь можно выкачивать все остальное - для этого удаляем папку из исключений (правый клик, Remove path from excluded) и выкачиваем в проект(Download from here)
Проект готов к работе:
Работаем с проектом Помимо стандартных фич (автодополнение кода, проверка на ошибки и т.д.) в PhpStorm есть множество возможностей, которые могут послужить стимулом для миграции
Генерация html, посмотреть можно
Автоформатирование кода (особенно актуально, если приходится разбирать стандартные компоненты и шаблоны битрикса)
Одна из проблем битрикса - тяжелое наследие из старого кода, очень многие методы, которые по факту являются static, объявлены как обычные. Из-за этого автодополнение в phpstorm не может их подхватить. Решается эта проблема исключением из проекта папки bitrix/modules и подключение этой папки из замечательного проекта
Еще одной киллер-фичей являются сниппеты для подключения компонентов. Для этого необходимо установить и добавлять компоненты из IDE простым нажатием комбинации Ctrl+J
Коллеги Нужна помощь! Случайно нажал не ту комбинацию клавиш и все открытые на редактирование файлы закрылись и удалились как локально так и на сервере!!!
Как можно откатить это действие, или восстановить их? Убил init.php и еще ряд файлов....
При создании проекта исключил папку /bitrix/components/ как теперь ее вернуть что бы она выгрузилась локально и индексировалась? Remove Path From Exluded выставлял, Deployment => Download... на папке локальной bitrix выставлял толку ноль! Не загружается! Как быть то не могу понять.... Подскажите пожалуйста!
Для php довольно давно существует менеджер зависимостей под названием composer, который позволяет одной командой устанавливать и обновлять библиотеки вместе с зависимостями. Подробно о нем можно прочитать здесь: . я же в этом посте хочу показать как подключить его к битриксу на примере одного пакета, который использую в каждом проекте.
Я работаю под линуксом, поэтому примеры команд привожу для него, для windows думаю отличий будет немного.
Итак. Сначала необходимо установить composer. В корне проекта выполняем команду:
curl -sS https://getcomposer.org/installer | php
либо скачиваем с официального сайта и копируем в корень проекта.
Теперь можно приступать к установке пакетов. В этом посте для примера будем использовать пакет для вывода отладочной информации - leeoniya/dump-r. Устанавливаем его командой:
В корне проекта появилась папка vendor, в которую composer скачивает библиотеки, также там расположены служебные файлы и автозагрузчик классов, который необходимо подключить в /bitrix/php_interface/init.php:
Для пакета dump-r так же лучше добавить следующий код, который упрощает его использование в дальнейшем:
use dump_r\Core;
if (!function_exists('dump_r')) {
function dump_r($raw, $depth = 1000, $expand = 1, $ret = false) {
return Core::dump_r($raw, $depth, $expand, $ret);
}
}
Теперь можно его использовать в любом месте проекта через функцию dump_r($arr), выглядит это вот так: Вывод массива организован в виде дерева, с возможностью сворачивать/разворачивать узлы, подсветкой и прочими плюшками. jquery не требуется.
Таким же образом можно подключать любые другие библиотеки, например phpexcel:
php composer.phar require phpexcel/phpexcel 1.7.7
И использовать в любом месте проекта без лишних телодвижений (автозагрузчик классов, который мы добавили в init.php сделает все за нас).
Последнее время на меня валится большое количество шаблонных проектов и становится скучно. Приходится развлекаться на стороне =) Сразу оговорюсь - подключение к битриксу шаблонизатора это скорее теоретические изыскание, на практике нигде не применял, поэтому особенно интересно мнение сообщества - какие вы видите в этом плюсы и минусы. Также цель поста - попиарить проект =) Итак - начнем. Подключить шаблонизатор к битрикс довольно просто - надо задать глобальную переменную arCustomTemplateEngines и описать в ней используемые шаблонизаторы с привязкой к расширениям, в общих чертах делается это так:
$loader = new \Twig_Loader_Filesystem(array($_SERVER['DOCUMENT_ROOT']));
$GLOBALS['twig'] = new \Twig_Environment($loader,array(
'debug' => true,
));
$GLOBALS['twig']->addExtension(new \Twig_Extension_Debug());
function twigRender($templateFile, $arResult, $arParams, $arLangMessages, $templateFolder, $parentTemplateFolder, $template){
$arResult['PARAMS']=$arParams;
echo $GLOBALS['twig']->render($templateFile,$arResult);
}
И можно использовать в шаблонах компонентов, создав файл template.twig, взамен template.php.
В общих чертах, зачем это может быть нужно. Плюсы
Более лаконичный синтаксис, по сравнению с php-шаблонами
Отсутствие соблазнов использовать в шаблоне выборку и обработку данных
Расширяемость - очень легко задавать собственные функции, фильтры и даже лексемы
Минусы
Синтаксис php знают все, синтаксис twig необходимо учить
php-шаблоны отрабатывают быстрее, но с учетом что все и так держится на кэшировании - не очень большой минус
Битрикс поддерживает шаблонизаторы только для компонентов, шаблоны сайтов все равно останутся в php
Для примера - шаблон всем известного news.list на Twig, в шаблоне используются нестандартные функции-обертки над функционалом битрикса: AddBitrixActions, GetEditAreaId и ResizeImageView. Реализацию этих функций можно увидеть здесь:
<div class="news-list">
{%if PARAMS.DISPLAY_TOP_PAGER=="Y" %}
{{ NAV_STRING | raw }}<br>
{%endif%}
{%for item in ITEMS%}
{{ AddBitrixActions(item) }}
<p class="news-item" id="{{ GetEditAreaId(item) }}">
{% if PARAMS.DISPLAY_PICTURE != "N" and item.PREVIEW_PICTURE is iterable %}
{% if not PARAMS.HIDE_LINK_WHEN_NO_DETAIL or (item.DETAIL_TEXT and USER_HAVE_ACCESS) %}
<a href="{{ item.DETAIL_PAGE_URL }}">
{{ ResizeImageView(item.PREVIEW_PICTURE.ID,100,100,{'class':'preview_picture','alt':item.PREVIEW_PICTURE.TITLE}) | raw }}
</a>
{% else %}
{{ ResizeImageView(item.PREVIEW_PICTURE.ID,50,50,{'class':'preview_picture','alt':item.PREVIEW_PICTURE.TITLE}) | raw }}
{% endif %}
{% endif %}
{% if PARAMS.DISPLAY_DATE!="N" and item.DISPLAY_ACTIVE_FROM %}
<span class="news-date-time">{{ item.DISPLAY_ACTIVE_FROM }}</span>
{% endif %}
{% if PARAMS.DISPLAY_NAME!="N" and item.NAME %}
{% if PARAMS.HIDE_LINK_WHEN_NO_DETAIL or (item.DETAIL_TEXT and USER_HAVE_ACCESS) %}
<a href="{{ item.DETAIL_PAGE_URL }}"><b>{{ item.NAME }}</b></a><br />
{% else %}
<b>{{ item.NAME }}</b><br>
{% endif %}
{% endif %}
{% if PARAMS.DISPLAY_PREVIEW_TEXT!="N" and item.PREVIEW_TEXT %}
{{ item.PREVIEW_TEXT }}
{% endif %}
{% if PARAMS.DISPLAY_PICTURE!="N" and item.PREVIEW_PICTURE is iterable %}
<div style="clear: both;"></div>
{% endif %}
{% for property in item.DISPLAY_PROPERTIES %}
<small>
{{ property.NAME }}:
{% if(property.DISPLAY_VALUE is iterable) %}
{{ property.DISPLAY_VALUE | join(" / ") }}
{% else %}
property.DISPLAY_VALUE
{% endif %}
</small><br>
{% endfor %}
</p>
{%endfor%}
{%if PARAMS.DISPLAY_BOTTOM_PAGER=="Y"%}
{{ NAV_STRING | raw }}<br>
{%endif%}
</div>
И в качестве эпилога. Twig, а также Doctrine2, php-console и еще много пока немного всего можно подключить буквально несколькими строчками установив пакет dizzy7/bitrix-libs с помощью Composer(как это сделать писал тут ). Более подробно установка описана на . Буду благодарен за критику и рекомендации инструментов и библиотек, которые вы используете в разработке, и которые можно было бы включить в этот набор.
На наших проектах мы используем схему, когда верстальщик верстает отдельно на своем сервере, где использует все удобные ему технологии (SSI, SAAS, LESS, Foundation, и др), благорадя чему верстает очень быстро, до 5 страниц среднего сайта за день.
Потом программист эту верстку программирует.
Когда на проекте возникают доработки где нужно править рабочий код (например, изменился внешний вид страницы товара) то верстальщик вносит правки на своем сервере для верстки, и комитит изменния через систему контроля версий в Битбакет. Программист когда приступает к внесению правок - полностью перезаливает все стили и js с сервера верстки (так как изменений в них может вносить только верстальщик) и изменяет html-структуру запрограммированного шаблона (видя через историю контроля версий в каких местах вносились правки).
Как правило, это работает быстро и надежно и достаточно программиста даже начального уровня чтобы перенести правки с верстки на рабочий сервер. Но как всегда - хочется автоматизации, поэтмоу рассматриваем вариант когда даже такого ручного переноса не понадобится.
По поводу 10-ти уровней - я имел ввиду такую структуру: /bitrix/templates/s1/components/bitrix/catalog/main-cat/bitrix/catalog.section/.default/template.php (тут даже 12 каталогов вышло) поэтому ищем способ чтобы все шаблоны (все файлики /template.php) лежали в одном месте на проекте (максимум с одним уровнем вложенности), например, так:
/local/html_templates/ - prodlist.tpl - category.tpl - subcategory.tpl - body.tpl - feedback.tpl - ... и тд чтобы верстальщик видел все шаблоны в одной папочке, и для него было просто и комфортно их править.
верстальщику проще править костяк шаблона когда это один файл (где видно структуру вложенности дивов), а если он должен помнить что в header.php он открыл 4 дива, и должен их закрыть в footer.php то это усложняет и запутывает разработку.
Типичная, хорошая схема. Но её слабость заключается в том, что после каждого чиха верстальщика нужен бэкэнд-разработчик. Как ни крути, но внёсший правки в вёрстку быстрее поправит шаблоны. Это особенно удобно на горячих проектах: каждый занимается своими делами, никого не надо дёргать из-за мелких правок.
Вот вы говорите про объединение шапки и подвала в один файл. Честно, мне кажется, это надуманная проблема. «Чистая» вёрстка собирается отдельно (просто ХТМЛ-страницы или компилирование, не важно), а потом уже её куски перетаскивают в шаблоны. Копи-паст, в общем.
С шаблонами в /local/html_templates/, думаю, могут возникнуть подводные камни, если проект будет расти. Тут надо учитывать те же зоны компонентов, многосайтовость.
Тема автоматизации широка и интересна. Главное, автоматизируя, как минимум, не терять того функционала, который был ранее : )
Иногда возникают ситуации, когда нет пароля от учетной записи администратора, но есть ftp. В этом случае можно использовать простенький скрипт, который авторизует пользователя и удаляет себя, для исключения потенциальных дыр в безопасности.
<? require($_SERVER["DOCUMENT_ROOT"] . "/bitrix/header.php");
global $USER;
$USER->Authorize(1);
@unlink(__FILE__);
LocalRedirect("/bitrix/admin/");
require($_SERVER["DOCUMENT_ROOT"]."/bitrix/footer.php");?>
Платонов Дмитрий, да, видимо битрикс перехватывает управление из-за прав доступа. Проверьте файлы .access.php в папке со скриптом и родительтских папках - возможно на время действия скрипта их придется переименовать/удалить
Сижу, никого не трогаю, в очередной тысяча-первый раз пишу $APPLICATION->AddHeadScript(), и вдруг phpstorm его перечеркивает... Разработчики битрикса наконец-то узнали о тэге "deprecated" и определение этого метода выглядит как /** @deprecated use Asset::getInstance()->addJs($src, $additional) */ function AddHeadScript($src, $additional=false)
Что же, отрадно, неужели и правда жизнь налаживается? =)
Цупко Игорь, в целом про разные среды мысль здравая, хотя в целом на локальных машинах можно использовать для создания идентичных сред у разработчиков и на продакшене. Для меня разрабатывать- на локальной копии очень удобно - нет задержек на заливку файлов, с локального компа сайт открывается в разы быстрее, чем с удаленного.
Цупко Игорь, а как вы отладкой пользуетесь? Ведь для нормальной отладки через xDebug нужен весь стек вызовов страницы. Ну и плюс в разных ядрах разный набор модулей/функций. Лишний автокомплит ведь ни к чему
@deprecated заметил тоже когда-то давно еще на GetIBlockElement()
Зацепин Евгений, согласен про разработку на локальной копии с ядром (правда у нас еще все синхронизируется с девелоп-сервером, и по сути код лежит локально, а работает - на сервере). Всегда можно внести изменения в ядро, полопатить его как следует.
Доброго времени суток. Набросал на коленке сервис генерации прокси-классов для работы с SOAP (генерация производится на основе wsdl). Сервис основан на доработанной .
Как водится кратко - зачем, почему, и какая польза =) 1. Прокси-классы предоставляют удобный ООП интерфейс 2. У всех soap-функций работает автодополнение в любой IDE 3. Возвращаемые данные также оборачиваются в соответствующие классы.
Зайцев Артемий, если перечислять только функции, то конечно можно обойтись и одним файлом. Здесь же обернуты в классы в том числе и параметры и возвращаемый результат, что и создает возможность удобной работы. Например можно писать такие запросы
$result = $soap->SendDemand(new \KTSoap\SendDemand(
11766,
'http://google.com',
new \KTSoap\TouristsToDemand([
new \KTSoap\TouristToDemand(
'Иванов'
'Иван'
'Иванович'
]
),
false
));
По параметрам кострурторов сразу понятно какие параметры нужны на входе, в т.ч. вложенные сущности. На выходе определенный объект, по которому так же понятно какие данные вернул сервер.
Смысл экономить на файлах? Да, все классы можно объединить в один файл, но зачем?
Группы на сайте создаются не только сотрудниками «1С-Битрикс», но и партнерами компании. Поэтому мнения участников групп могут не совпадать с позицией компании «1С-Битрикс».
Группы на сайте создаются не только сотрудниками «1С-Битрикс», но и партнерами компании. Поэтому мнения участников групп могут не совпадать с позицией компании «1С-Битрикс».
там на самом деле очень много надо сделать, а времени нет. Хотя бы доделать апи для связки elasticsearch и битрикса (добавление в индекс и получение из индекса). После этого уже можно говорить о каких-то компонентах и модулях. И то, это всё очень специфично. А в битриксе сейчас появились фасеты, поэтому уже часть задачи отпало. Хотя с elasticsearch можно забабахать офигенный поиск с ранжированием и фильтрацией.