Регистрация: email в качестве логина и нужная группа пользователей.
Регистрация пользователей – одна из наиболее востребованных частей функционала веб-проекта. В Битриксе есть для этого 2 инструмента: стандартная регистрация и настраиваемая. Если необходимо более гибкое решение рекомендую остановиться на втором варианте. Все хорошо, но если чего-то не хватает … что делать? Можно попросить Битрикс реализовать нужный Вам функционал, можно обратиться к стороннему разработчику или все написать самому. Я, как разработчик, выберу последний вариант.
Сам неоднократно сталкивался с ситуацией, когда нужно email использовать вместо логина или зарегистрированного помещать в группу пользователей, отличную от группы в настройках главного модуля. В качестве основы я выбрал стандартный компонент «Настраиваемая регистрация» (можно и с нуля написать кто хочет). Начинаем кастомизировать. После копирования компонента заходив в его папку и начинаем редактировать component.php. Нам необходимо дописать / заменить несколько строк.
if($def_group != "")
{
// check user group
if("Y" == $arParams["USE_GROUP"]) $arResult["VALUES"]["GROUP_ID"] = array(intVal($arParams["USER_GROUP"]));
else $arResult["VALUES"]["GROUP_ID"] = explode(",", $def_group);
}
// set EMAIL as LOGIN
if($arParams["USE_EMAIL_TO_LOGIN"] == "Y") $arResult["VALUES"]["LOGIN"] = $arResult["VALUES"]["EMAIL"];
Компонент для регистрации использует метод CUser::Add, поэтому нам добавлять в логику больше ничего не нужно. Остается только подредактировать файл .parameters.php (чтобы все дополнительные опции мы смогли бы включить в компоненте). Как видите все просто. Ну а для тех кто не хочет копаться к кодах, выпустил готовое решение – http://marketplace.1c-bitrix.ru/solut...isterplus/
Клёпов Роман, А вы не думали, что от того, что уберем опцию, толку будет 0, т.к. логин = email? В крайнем случае можно вынести в настройки модуля настроек сайта, прошу прощения за тавтологию. Но еще ни разу не встречал, чтобы авторизацию надо было вернуть по логину обратно.
Ой, там целая кастомизация компонента.. Во-первых, ради такой вещи кастомизировать компонент нет смысла. Во-вторых, что вы будете делать с системной регистрацией? А она может выскочить в некоторых местах. Опять кастомизировать компонент? Это плохая практика. Кастомизация предполагает внесение функционала, который по другому без сильного проседания производительности или в общем не реализовать.
На неделе столкнулся с задачей вывода топ-20 брендов. Для магазина есть удобные инструменты: компоненты Бренды (для справочников) и топ товаров. Объединив оба результата можно добиться необходимого вывода.
Я решил поступить немного иначе: сделать выборку 100 (200) топовых товаров и вытянуть у них необходимые бренды (бренды были заданы свойством инфоблока, привязка к элементу). Затем, отсеяв дубли, получить топ уникальных брендов.
Рано или поздно, любой разработчик Битрикс сталкивается с ситуацией, когда базового функционала ему перестает хватать. Именно тогда ему и приходится вникать в процесс разработки компонентов(или модулей). На первый взгляд задача кажется достаточно сложной, но изучив суть вопроса, она такой не является. Смотря книги (обычные печатные), почитая статьи и форумы в интернете, я находил материал, который может дать только поверхностное представление о компонентах. Но, думаю, для понимания его принципа работы и грамотного написания стоит изучить архитектуру Битрикс Фреймворк. Архитектура этой платформы строится по модели MVC(модель – представление - поведение):
модель – это API,
представление – это шаблон,
поведение – это компонент.
На рисунке сплошными линиями отмечены прямые связи, пунктиром – косвенные. Теперь давайте рассмотрим, что из себя представляет компонент Битрикс. Компонент – логически законченный код (логика), который получает информацию и выводит ее в определенной форме(шаблон, как правило html). Используемые в Битрикс компоненты можно разделить на простые(одностраничные) и комплексные(набор простых, многостраничные).
Структура компонента
Компоненты Битрикс расположены в отдельных папках, имеют чёткую структуру и обладают свойствами неделимости(их файлы нельзя использовать по отдельности).
Папки:
help не является обязательной, в ней располагаются файлы помощи,
install содержит скрипты по установки(и удалению) компонента, ее наличие не обязательно в системе,
lang содержит подпапки для языковых параметров компонента, ее наличие тоже не является обязательным,
templates содержит шаблоны компонента, если у компонента нет шаблона, то папка может отсутствовать.
Файлы:
сomponent.php содержит логику компонента, его наличие всегда обязательно,
.description.php является необходимым, служит для задания названия, описание, нахождения в дереве логического размещения (визуального редактора),
.parameters.php – необходим для задания параметров. Если у компонента нет вводимых параметров, файл может отсутствовать.
Стоит отметить, что компонент может содержать и другие папки и файлы, необходимые в своей работе(например, папку images, js, css и пр.) .
Расположение компонента
Все компоненты Битрикс бывают системными и пользовательскими, они располагаются в /bitrix/components/. Системные находятся в /bitrix/components/bitrix/, пользовательские – в самой папке в /bitrix/components/ или любых других подпапках. Размещение пользовательских компонентов в папке /bitrix/components/bitrix/ крайне не рекомендуется, т.к. они будут затерты после первого обновления системы. Также не рекомендуется менять системные компоненты, итоги таких изменений могут быть плачевными.
На этом заканчиваю «сухую» теорию компонентов. Статья сыроватая, вскоре может быть дополнена или даже переписана.
> как потом определять разработчику после вас, это кастомный компонент или типовой Использовать свой, оригинальный префикс. Я не агитирую делать это всегда, просто есть случаи когда так удобнее.
Проблема битркса в том, что сопоставление API - Модель достаточно слабое. API млишком низкоуровненое и моделирует сущьности самой системы, а не предметной области. Если вам нужно смоделировать например сущьность "товар типа книга", то есть дав пути: - заклчать всю логику в компонентах, что приводит к децентрализации логики поведения модели (ведь в компоненте как правило участвует несколько сущьностей), и копированию кода (ведь одно поведение может быть использовано в нескольких разных компонентах) - свои классы моделей - тру-ООП путь, но есть минус - так как битрикс не предоставляет никаких соглашений на использование моделей предметной области, то написание модели - это почти всегда велосипед. Стандартные компоненты используют первый подход, а это значит, если вы хотите быть тру-ООП разработчиком то все компоненты, в которых задействованы ваши модели нужно писать самостоятельно копируя и адаптируя под новый подход тонны кода из стандартных.
Теперь необходимо сверстать как обычную html страницу. Наша задача упрощается тем, что html-шаблон уже есть и его можно скачать. Для любителей поверстать: есть множество шаблонов psd в сети интернет, которые можете использовать для тренировки, ссылки давать не буду(Google всегда поможет (= ). Не стоит акцентировать внимание на самой верстке, т.к. это выйдет за рамки статьи, но отмечу, что используется корректный html5 и css3(valid). Структура шаблона в нашем случае будет выглядеть:
В папки css, images и js я поместил файлы .htaccess с содержимым: Options –Indexes для запрета отображения содержимого папки. В папки include_areas и page_templates поместил файлы .htaccess: Deny from all для запрета любого обращения к этой папке(со стороны пользователей). Когда все готово папку с шаблоном необходимо закачать на сайт в директорию /bitrix/templates/ Остается проверить шаблон в действии. Перейдите в раздел Настройки-> Сайты -> Список сайтов.
Изменяем настройки нужного сайта. На открывшейся странице( в самом низу) в разделе Шаблон: выбираем наш шаблон(Тестовый шаблон) и нажимаем кнопку Сохранить. На этом урок закончен. Комментариям и критике всегда рад!
А первую в мире книжку по Битриксу кто нибудь читал? бумажную такую не шибко толстенькую, но все же в твердой обложке? Сейчас наверное она безбожно устарела....
Рано или поздно, любой разработчик Битрикс сталкивается с ситуацией, когда базового функционала ему перестает хватать. Именно тогда ему и приходится вникать в процесс разработки компонентов(или модулей). На первый взгляд задача кажется достаточно сложной, но изучив суть вопроса, она такой не является. Смотря книги (обычные печатные), почитая статьи и форумы в интернете, я находил материал, который может дать только поверхностное представление о компонентах. Но, думаю, для понимания его принципа работы и грамотного написания стоит изучить архитектуру Битрикс Фреймворк. Архитектура этой платформы строится по модели MVC(модель – представление - поведение):
модель – это API,
представление – это шаблон,
поведение – это компонент.
На рисунке сплошными линиями отмечены прямые связи, пунктиром – косвенные. Теперь давайте рассмотрим, что из себя представляет компонент Битрикс. Компонент – логически законченный код (логика), который получает информацию и выводит ее в определенной форме(шаблон, как правило html). Используемые в Битрикс компоненты можно разделить на простые(одностраничные) и комплексные(набор простых, многостраничные).
Структура компонента
Компоненты Битрикс расположены в отдельных папках, имеют чёткую структуру и обладают свойствами неделимости(их файлы нельзя использовать по отдельности).
Папки:
help не является обязательной, в ней располагаются файлы помощи,
install содержит скрипты по установки(и удалению) компонента, ее наличие не обязательно в системе,
lang содержит подпапки для языковых параметров компонента, ее наличие тоже не является обязательным,
templates содержит шаблоны компонента, если у компонента нет шаблона, то папка может отсутствовать.
Файлы:
сomponent.php содержит логику компонента, его наличие всегда обязательно,
.description.php является необходимым, служит для задания названия, описание, нахождения в дереве логического размещения (визуального редактора),
.parameters.php – необходим для задания параметров. Если у компонента нет вводимых параметров, файл может отсутствовать.
Стоит отметить, что компонент может содержать и другие папки и файлы, необходимые в своей работе(например, папку images, js, css и пр.) .
Расположение компонента
Все компоненты Битрикс бывают системными и пользовательскими, они располагаются в /bitrix/components/. Системные находятся в /bitrix/components/bitrix/, пользовательские – в самой папке в /bitrix/components/ или любых других подпапках. Размещение пользовательских компонентов в папке /bitrix/components/bitrix/ крайне не рекомендуется, т.к. они будут затерты после первого обновления системы. Также не рекомендуется менять системные компоненты, итоги таких изменений могут быть плачевными.
На этом заканчиваю «сухую» теорию компонентов. Статья сыроватая, вскоре может быть дополнена или даже переписана.
> как потом определять разработчику после вас, это кастомный компонент или типовой Использовать свой, оригинальный префикс. Я не агитирую делать это всегда, просто есть случаи когда так удобнее.
Проблема битркса в том, что сопоставление API - Модель достаточно слабое. API млишком низкоуровненое и моделирует сущьности самой системы, а не предметной области. Если вам нужно смоделировать например сущьность "товар типа книга", то есть дав пути: - заклчать всю логику в компонентах, что приводит к децентрализации логики поведения модели (ведь в компоненте как правило участвует несколько сущьностей), и копированию кода (ведь одно поведение может быть использовано в нескольких разных компонентах) - свои классы моделей - тру-ООП путь, но есть минус - так как битрикс не предоставляет никаких соглашений на использование моделей предметной области, то написание модели - это почти всегда велосипед. Стандартные компоненты используют первый подход, а это значит, если вы хотите быть тру-ООП разработчиком то все компоненты, в которых задействованы ваши модели нужно писать самостоятельно копируя и адаптируя под новый подход тонны кода из стандартных.
Рано или поздно, любой разработчик Битрикс сталкивается с ситуацией, когда базового функционала ему перестает хватать. Именно тогда ему и приходится вникать в процесс разработки компонентов(или модулей). На первый взгляд задача кажется достаточно сложной, но изучив суть вопроса, она такой не является. Смотря книги (обычные печатные), почитая статьи и форумы в интернете, я находил материал, который может дать только поверхностное представление о компонентах. Но, думаю, для понимания его принципа работы и грамотного написания стоит изучить архитектуру Битрикс Фреймворк. Архитектура этой платформы строится по модели MVC(модель – представление - поведение):
модель – это API,
представление – это шаблон,
поведение – это компонент.
На рисунке сплошными линиями отмечены прямые связи, пунктиром – косвенные. Теперь давайте рассмотрим, что из себя представляет компонент Битрикс. Компонент – логически законченный код (логика), который получает информацию и выводит ее в определенной форме(шаблон, как правило html). Используемые в Битрикс компоненты можно разделить на простые(одностраничные) и комплексные(набор простых, многостраничные).
Структура компонента
Компоненты Битрикс расположены в отдельных папках, имеют чёткую структуру и обладают свойствами неделимости(их файлы нельзя использовать по отдельности).
Папки:
help не является обязательной, в ней располагаются файлы помощи,
install содержит скрипты по установки(и удалению) компонента, ее наличие не обязательно в системе,
lang содержит подпапки для языковых параметров компонента, ее наличие тоже не является обязательным,
templates содержит шаблоны компонента, если у компонента нет шаблона, то папка может отсутствовать.
Файлы:
сomponent.php содержит логику компонента, его наличие всегда обязательно,
.description.php является необходимым, служит для задания названия, описание, нахождения в дереве логического размещения (визуального редактора),
.parameters.php – необходим для задания параметров. Если у компонента нет вводимых параметров, файл может отсутствовать.
Стоит отметить, что компонент может содержать и другие папки и файлы, необходимые в своей работе(например, папку images, js, css и пр.) .
Расположение компонента
Все компоненты Битрикс бывают системными и пользовательскими, они располагаются в /bitrix/components/. Системные находятся в /bitrix/components/bitrix/, пользовательские – в самой папке в /bitrix/components/ или любых других подпапках. Размещение пользовательских компонентов в папке /bitrix/components/bitrix/ крайне не рекомендуется, т.к. они будут затерты после первого обновления системы. Также не рекомендуется менять системные компоненты, итоги таких изменений могут быть плачевными.
На этом заканчиваю «сухую» теорию компонентов. Статья сыроватая, вскоре может быть дополнена или даже переписана.
> как потом определять разработчику после вас, это кастомный компонент или типовой Использовать свой, оригинальный префикс. Я не агитирую делать это всегда, просто есть случаи когда так удобнее.
Проблема битркса в том, что сопоставление API - Модель достаточно слабое. API млишком низкоуровненое и моделирует сущьности самой системы, а не предметной области. Если вам нужно смоделировать например сущьность "товар типа книга", то есть дав пути: - заклчать всю логику в компонентах, что приводит к децентрализации логики поведения модели (ведь в компоненте как правило участвует несколько сущьностей), и копированию кода (ведь одно поведение может быть использовано в нескольких разных компонентах) - свои классы моделей - тру-ООП путь, но есть минус - так как битрикс не предоставляет никаких соглашений на использование моделей предметной области, то написание модели - это почти всегда велосипед. Стандартные компоненты используют первый подход, а это значит, если вы хотите быть тру-ООП разработчиком то все компоненты, в которых задействованы ваши модели нужно писать самостоятельно копируя и адаптируя под новый подход тонны кода из стандартных.
Рано или поздно, любой разработчик Битрикс сталкивается с ситуацией, когда базового функционала ему перестает хватать. Именно тогда ему и приходится вникать в процесс разработки компонентов(или модулей). На первый взгляд задача кажется достаточно сложной, но изучив суть вопроса, она такой не является. Смотря книги (обычные печатные), почитая статьи и форумы в интернете, я находил материал, который может дать только поверхностное представление о компонентах. Но, думаю, для понимания его принципа работы и грамотного написания стоит изучить архитектуру Битрикс Фреймворк. Архитектура этой платформы строится по модели MVC(модель – представление - поведение):
модель – это API,
представление – это шаблон,
поведение – это компонент.
На рисунке сплошными линиями отмечены прямые связи, пунктиром – косвенные. Теперь давайте рассмотрим, что из себя представляет компонент Битрикс. Компонент – логически законченный код (логика), который получает информацию и выводит ее в определенной форме(шаблон, как правило html). Используемые в Битрикс компоненты можно разделить на простые(одностраничные) и комплексные(набор простых, многостраничные).
Структура компонента
Компоненты Битрикс расположены в отдельных папках, имеют чёткую структуру и обладают свойствами неделимости(их файлы нельзя использовать по отдельности).
Папки:
help не является обязательной, в ней располагаются файлы помощи,
install содержит скрипты по установки(и удалению) компонента, ее наличие не обязательно в системе,
lang содержит подпапки для языковых параметров компонента, ее наличие тоже не является обязательным,
templates содержит шаблоны компонента, если у компонента нет шаблона, то папка может отсутствовать.
Файлы:
сomponent.php содержит логику компонента, его наличие всегда обязательно,
.description.php является необходимым, служит для задания названия, описание, нахождения в дереве логического размещения (визуального редактора),
.parameters.php – необходим для задания параметров. Если у компонента нет вводимых параметров, файл может отсутствовать.
Стоит отметить, что компонент может содержать и другие папки и файлы, необходимые в своей работе(например, папку images, js, css и пр.) .
Расположение компонента
Все компоненты Битрикс бывают системными и пользовательскими, они располагаются в /bitrix/components/. Системные находятся в /bitrix/components/bitrix/, пользовательские – в самой папке в /bitrix/components/ или любых других подпапках. Размещение пользовательских компонентов в папке /bitrix/components/bitrix/ крайне не рекомендуется, т.к. они будут затерты после первого обновления системы. Также не рекомендуется менять системные компоненты, итоги таких изменений могут быть плачевными.
На этом заканчиваю «сухую» теорию компонентов. Статья сыроватая, вскоре может быть дополнена или даже переписана.
> как потом определять разработчику после вас, это кастомный компонент или типовой Использовать свой, оригинальный префикс. Я не агитирую делать это всегда, просто есть случаи когда так удобнее.
Проблема битркса в том, что сопоставление API - Модель достаточно слабое. API млишком низкоуровненое и моделирует сущьности самой системы, а не предметной области. Если вам нужно смоделировать например сущьность "товар типа книга", то есть дав пути: - заклчать всю логику в компонентах, что приводит к децентрализации логики поведения модели (ведь в компоненте как правило участвует несколько сущьностей), и копированию кода (ведь одно поведение может быть использовано в нескольких разных компонентах) - свои классы моделей - тру-ООП путь, но есть минус - так как битрикс не предоставляет никаких соглашений на использование моделей предметной области, то написание модели - это почти всегда велосипед. Стандартные компоненты используют первый подход, а это значит, если вы хотите быть тру-ООП разработчиком то все компоненты, в которых задействованы ваши модели нужно писать самостоятельно копируя и адаптируя под новый подход тонны кода из стандартных.
Эта статья адресована начинающим веб-разработчикам, которые, как и я недавно столкнулись с этой ЦМС.
Рано или поздно, знакомясь с этой системой, придётся лезть в исходные коды компонентов( и намного реже модулей). И тут нам в качестве базовых пригодятся знания языка php (т.к. наиболее функциональный продукт написан именно на нём), работа и настройки web-сервера Apache. Перед тем как начинать писать что-то своё, необходимо разобраться в архитектуре Битрикс. Читая документацию на офф. сайте, я только заходил в тупик и начинали путаться мысли. Как альтернативный вариант – решил купить печатную книгу. Просмотрев несколько вариантов, выбрал одну. Хочу предложить к прочтению и изучению книгу Роберта Басырова «1С-Битрикс: Корпоративный портал. Руководство разработчика». Книга достаточно логично и полно всё рассказывает. Как и следует из названия, ориентирована она на корпоративный портал, но основы одни и те же. Когда хоть какое-то будет представление о Битриксе, можно начать с самого простого – созданию шаблона. Тут множество информации, можно воспользоваться любым поисковиком. В качестве примера приведу пару полезных ссылок:
Для развитие своих навыков можно брать любые psd-макеты сайтов, верстать (обычный xhtml, css, js), а потом переводить на ЦМС. Когда шаблоны уже будут успешно и быстро верстаться и перестанут возникать различные вопросы(вроде: а почему это выводится в футере? и пр.), можно переходить к более творческой работе – программированию. Разработчики Битрикс(да и просто сторонние) настоятельно не рекомендуют сразу что-то модифицировать, лезть в исходники ядра, модулей, таблиц БД(МуSQL и пр.). В качестве основных инструментов разработки использовать компоненты – настройка, модификация и только в крайнем случае написание своего кода. Иногда вопрос можно решить настройкой компонента, чаще его модификацией(в основном шаблона вывода). Временами, не найдя нужного решения, придётся писать его самому. Перед тем как лезть в исходники и начинать изменения настоятельно рекомендую взять ручку и листок и нарисовать примерную схему работы компонента. И чем подробнее она будет, тем лучше – меньше времени потратите на ее реализацию! Когда схема готова можно перейти к программированию компонента. На самом деле это проще, чем кажется (если вы понимаете принцип работы ЦМС). Поискав информацию по данной теме нашел несколько полезных ссылок:
Для понимания работы компонента можно установить «Живой API» - http://marketplace.1c-bitrix.ru/solut...x.liveapi/ Также могу предложить посмотреть исходники системных(в папке /bitrix/component/bitrix/) и бесплатных с МаркетПлейса. Вообще, долго и упорно искав информацию, наткнулся на исходники проекта РосЯма. Он раньше был написан на платформе Битрикс. Сейчас эти исходники с трудом, но всё же можно найти в сети.
На этом хочу закончить статью. Как и писал вначале, она рассчитана на начинающих разработчиков, которые имеют базовые знания php, html+ css и хоть какие-то знания по работе серверов (в частности) и Apache(в конкретике). Позже будут рассмотрены практические решения задач.
Опыт не приходит со временем, он приходит с реализованными задачами и проектами. Старайтесь и всё у вас получится!
Планировал, что-то вроде вступления по написанию компонентов. Хочу создать серию уроков с примерами от простого к сложному. Пока переименовывать не буду.
Группы на сайте создаются не только сотрудниками «1С-Битрикс», но и партнерами компании. Поэтому мнения участников групп могут не совпадать с позицией компании «1С-Битрикс».