Что такое кастомизация в программировании

Битрикс. Введение в кастомизацию

Сегодня, разбирая хлам в Dropbox’е, я обнаружил эту статью, которую написал в 2010 году для корпоративного блога компании, в которой я тогда работал. Блог не состоялся, я больше Битриксом не занимаюсь и статья пропадает зря. Возможно, в она уже не актуальна, но, думаю, что основные принципы программирования на Битриксе за 4 года не изменились. Поэтому публикую статью здесь в надежде, что пригодиться.

Введение

В своей работе — а я занимаюсь разработкой сайтов на платформе — мне довольно часто приходится иметь дело с проектами, разработанными другими людьми. И в этих проектах регулярно встречаются настолько грязные хаки, инъекции и вообще кривой код, что удивляешься, как оно до сих пор работает. Раньше я не понимал, почему люди так не любят битрикс; почему говорят, что он медленно работает; почему для работы с сайтом на битриксе нужны знания HTML и PHP , ведь там почти всё сделано удобно и красиво. Теперь я начинаю понимать:)

В этом материале я хотел бы немного рассказать о принципах программирования для битрикса, точнее о 3 столпах разработки проектов на битриксе: шаблонах, компонентах, модулях. Зная, что это такое, можно разработать любой проект: и с суперуникальным ни на что не похожим дизайном и мощный с огромной посещаемостью. Причем они будут радовать своих посетителей скоростью работы (насколько это возможно для битрикса), а своих владельцев — удобством работы и поддержки. В статье я буду часто употреблять слово «кастомизация», как синоним «разработки», при этом имея в виду вообще заточку того или иного механизма под нужды конкретного проекта.

План статьи таков:

1. рассмотрим вкратце шаблоны, компоненты и модули;
2. посмотрим, на что они способны в плане кастомизации, коснёмся особых случаев;
3. приведём примеры.

Компоненты

Механизм компонентов не самый простой и не самый часто кастомизуемый, но я решил начать именно с него, потому что он является ядром логики проекта, именно он определяет, как всё вертится и работает. На сайте битрикса написано, что компонент — это «логически завершенный код, … принимающий ряд параметров, выполняющий ряд действий и выводящий результат». Знакомым с архитектурой MVC компонент может показаться похожим на контроллер и это действительно так. На вход компонент принимает массив параметров, на выходе отдаёт шаблону массив данных, а в процессе работы использует API модулей. Бесспорно, самый часто употребляемый компонент — список новостей. И это не потому, что на сайтах много новостей, а потому, что этим компонентом удобно выводить любые списки: будь то статьи, отзывы, FAQ или топ товаров. Другими примерами компонентов могут быть: компонент авторизации, корзины, меню.

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

Шаблоны

Шаблоны в битриксе, как и во многих других системах, выполняют функцию отображения данных. Как я уже говорил, компонент передаёт в шаблон массив данных, а задача шаблона — преобразовать этот массив в удобоваримый вид, например, в . Шаблоны — это самый простой и самый часто используемый способ кастомизации.

Да, я обещал сказать, чем отличаются шаблоны компонент от шаблонов страниц. Шаблоны компонент визуализируют данные, предоставленные компонентом, а шаблоны страниц формируют некий layout — определяют области для шапки, меню, основного контента В этой статья я говорю только о шаблонах компонентов.

Помнишь, дорогой читатель, про самый часто употребляемый компонент — список новостей? Он такой универсальный как раз благодаря шаблонам. Именно они позволяют превратить список файлов для скачивания в фотогалерею, а фотогалерею — в отзывы партнёров.

Модули

В простейшем случае модуль — это класс или набор классов, методы которого формируют API для использования в компонентах. Обычно, вместе с модулем поставляется некоторый набор компонентов. Например, с модулем поиска мы получаем такие компоненты как: Облако тегов, Стандартная страница поиска, Форма поиска и др. Количество и состав модулей, входящих в стандартную поставку, зависит от редакции битрикса. Разумеется, с каждым компонентом поставляется минимум один шаблон.

Ну вот про основы я рассказал и, перед тем как перейти к кастомизации, хочу обратить внимание на 2 принципа разработки под битрикс:

1. Никаких запросов к базе данных! Про существование БД вообще лучше забыть и пользоваться только возможностями, предоставляемыми API модулей. Сами производители платформы мотивируют это тем, что они могут изменить формат БД в любой момент и этого сайт перестанет работать. Единственный случай, когда можно использовать прямые запросы к БД — это обращение к таблицам, созданным непосредственно вами.
2. Нельзя изменять системные файлы, включая стандартные шаблоны, компоненты, модули. Дело в том, что всё это может быть затёрто ближайшим обновлением и всё труды пойдут насмарку. Можно создать свои с нуля или скопировав готовые и изменять уже их.

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

Кастомизация

Самая лучшая кастомизация — это отсутствие кастомизации. Почему? Потому что, написав свой код, его придётся поддерживать: исправлять в нём баги, закрывать дыры и наращивать функционал. Зачем делать лишнюю работу, если можно её свалить на плечи разработчиков битрикса? Таким образом, если можно ограничиться только настройками существующего — ограничиваемся ими, если нет — читаем статью дальше.

Самое простое, что можно сделать в целях кастомизации — изменить шаблон. Компонент на выходе выдаёт огромную гору данных, из которых можно много чего соорудить. Для изменения внешнего вида, не затрагивающего логику, этот способ подходит лучше всего.

Например, хотим в шапке на главной устроить слайдшоу из нескольких картинок. Нет ничего проще! Нужно завести для картинок отдельный инфоблок, а затем вывести их стандартным компонентом новостей. Хранить картинки удобнее всего в свойстве «картинка для анонса», так как оно поддерживает автоматическое масштабирование. Для этого компонента нужно сделать специальный шаблон, который будет формировать HTML для картинок. В этом же шаблоне на картинки натравливаем jQuery’вский плагин для слайдшоу — всё готово.

Уже в этом месте можно остановиться и обратить внимание на ошибки. Многие прожженные программеры, которым поставят задачу сделать слайдшоу, решат её так: зальют в папочку на серваке картинки, а на странице воткнут соответствующий и вызов . Задача выполнена, заказчик счастлив. Геморрой начнётся тогда, когда понадобится сделать второе такое слайдшоу, поменять картинки или сделать картинки ссылками. Чтобы это сделать, придётся позовать того же программера, который сделает второе такое же слайдшоу. Я конечно утрирую, и большинство разумных и не слишком ленивых программеров решит задачу правильно, но и с такими случаями я тоже сталкивался.

Внимание, нюанс! Если вы, как и я, везде включаете кэширование и подключаете скрипты не прямо , а используете отложенную функцию «AddHeadScript», то вас поджидает сюрприз. При включенном кэшировании скрипт не будет подключаться. Это и логично, ведь результат работы компонента закэшировался и никакие функции вызываться не будут. На наше счастье, в последних версиях битрикса появился файлик component_epilog.php , который вызывается после работы шаблона и не кэшируется.

А теперь представим, что у нас на сайте 5 слайдшоу, которые отличаются спецэффектом перехода между картинками, временем показа каждой, ну и разумеется показываются разные картинки, причем для некоторых из них могут быть указаны ссылки, чтобы при клике на картинку переходить . Давайте накопипастим 5 шаблонов! Это метод экстенсивный, поэтому мы пойдём другой путёй. Шаблоны компонентов могут иметь свои настройки, как и сами компоненты. Ничто не мешает нам вынести в них и эффекты переходов, и длительности, и вообще, все, что угодно. А что делать с самими картинками и ссылками? , элементы инфоблока можно организовывать в иерархические . Если сделать по одной для каждого слайдшоу, то это решит первую проблему. , инфоблоки для того и существуют, чтобы у их элементов было много разных свойст. Так что ссылки можно хранить в отдельном свойстве. Вот теперь заказчик счастлив, потому что сам может и картинки загружать и эффекты выбирать.

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

Я обещал коснуться особых случаев. Как я уже говорил, страницы в битриксе — это реально существующие файлы, поэтому никто не мешает писать прямо в них. Многие, очень многие этим злоупотребляют! Что может быть проще, чем прямо на странице нахардкодить нужный функционал? Зачем заморачиваться с компонентами, копировать шаблоны? А я скажу зачем! , мало кто догадается свой код снабдить системой кэширования. А в компонентах она уже есть. , как весь этот код править через визуальный редактор? Ну и , это очень тяжело поддерживать.

Однако существует один случай, когда можно кодить прямо на странице. Помнишь, когда мы писали свой компонент для слайдшоу? Так вот эту же задачу можно было решить, задав фильтр для стандартного компонента. Фильтр как раз и будет тем кодом, который нужно написать на странице перед вызовом компонента. Он мал и прост, поэтому визуальный редактор не сойдёт с ума при встрече с ним.

Примеры

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

Задача: вывести в тег title не только название текущей страницы, но и список всех родительских разделов в обратном порядке вплоть до корня.
Решение: вставить в тег title компонент навигационной цепочки с кастомизованным шаблоном.

Задача: сделать 2 списка новостей: для главной страницы — со ссылкой на все новости, для внутренней — с пагинатором. Позже задача расширилась: надо было точно таким же образом оформить акции компании, новые решения и советы.
Решение: сделать параметризованный шаблон. В параметры попадают названия блоков и текст ссылки на все новости (акции, советы ) Шаблон очень легко и просто расширяется.

Задача: вывести в корзине полное описание товаров.
Решение: кастомизовать шаблон. Нужную выборку сделать в файле «result_modifier.php ».

Задача: вывести форму авторизации в попапе.
Решение: кастомизовать шаблон.

Задача: сделать так, чтобы в списке товаров по умолчанию отображались все свойства инфоблоков, кроме тех, что начинаются с «_».
Решение: кастомизовать компонент.

Задача: сделать так, чтобы можно было оставлять отзывы и оценки на товары. Предусмотреть возможность премодерации.
Решение: написать новый модуль.

Заключение

Хорошие разработчики и программеры не почерпнули из статьи ничего нового, плохие — вспомнили свои ошибки и забили на них, остальные — намотали на ус

О кастомизации информационных систем

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

Возможные подходы

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

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

Можно, конечно, сразу думать о будущих переводах на новую версию продукта и организовывать код таким образом, что все специфичные изменения будут располагаться максимально в стороне от кода основного продукта. В идеальном мире это бы сработало, но мы с вами живем в суровой реальности, где часто срок выполнения задачи может быть объявлен как “вчера”, и работает над проектом отнюдь не компактная команда классных профессионалов, а батальон вчерашних студентов. В таких ситуациях люди редко задумываются об архитектуре и идут по пути наименьшего сопротивления — нашел место, где надо поправить, удалил старое, написал новое. Это, кстати, ведет к еще одной большой проблеме — логика расширения перемешивается с логикой продукта.

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

• Entity — хранит ссылку на объект, поле которого мы описываем. Обычно это идентификатор сущности;
• Attribute — ссылка на определение атрибута (об этом ниже);
• Value — собственно значение атрибута.

• тип атрибута;
• ограничения (длина поля, регулярное выражение, которому должно соответствовать значение и пр.);
• компонент для отображения в UI;
• порядок отображения компонента в UI.

1. Реализовать механизм задания метаданных, с помощью которого мы сможем, например, указать, что к сущностям типа “Договор” добавится новый атрибут «Дата расторжения», тип поля — «Дата», компонент для отображения — DateField.
2. Реализовать механизмы отображения и ввода значений динамических атрибутов на необходимых экранах продукта. Механизм должен находить возможный набор атрибутов для данной сущности в таблице с описанием метаданных, отображать компоненты для их редактирования, а затем в таблице с данными искать и отображать их значения, сохраняя их при закрытии экрана.

Далее о недостатках. Во-первых, это ограниченность применения. Модель EAV позволит лишь добавить атрибуты в сущность и отобразить их в заранее определенном месте на экране. Не более того. Об изменении функциональности, хитрых UI-компонентах здесь речи не идет.

Во-вторых, EAV модель создает большую дополнительную нагрузку на сервер БД. Для загрузки одного экземпляра сущности без связей потребуется чтение вместо одной нескольких строк таблицы. Для загрузки списка экземпляров, например в таблицу на UI, вообще потребуется N+1 запросов, либо джойны по числу колонок таблицы. Учитывая, что база данных в корпоративных системах и так чаще всего является самым медленным и плохо масштабируемым элементом, такая дополнительная нагрузка может просто убить систему.

В-третьих, опять же из-за структуры базы будет довольно сложно делать выборки данных для отчетов — вместо написания обычного SQL для реляционных данных потребуются гораздо более сложные запросы.

Данная архитектура позволяет хранить дополнительную функциональность в отдельных артефактах — плагинах. Если ваш заказчик хочет какой-то новой специфики, то вы ставите ему базовый продукт, пишете плагин, подключаете его и готово. Для использования плагинов в продукте должны быть объявлены точки расширения. Что это такое? Если просто, то это определенные места в коде. В этих местах перебираются загруженные плагины, анализируется, есть ли в плагинах логика, предназначенная для данной точки расширения, и если такая логика находится, она выполняется. Примеры точек расширения: пункт меню, обрабочик команды, кнопка на тулбаре, новый экран.

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

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

Но и здесь, к сожалению, есть недостатки. Для каких-то продуктов они окажутся несущественными, для каких-то могут стать причиной невозможности использования плагинной архитектуры. Дело в том, что плагин может расширить систему лишь в том месте, где определена точка расширения. Бесспорно, существует класс продуктов, где таких мест в принципе немного и все они заранее определены, но есть также и огромная группа, для которой предугадать, что потребуется расширить завтра, практически невозможно. Анализ потенциальных расширяемых мест может стать очень ресурсоемким занятием, а в результате все равно оказаться не совсем точным. Кроме того, точки расширения — это усложнение основного кода, что всегда чревато ошибками и сложностью сопровождения. Подходить к определению точек расширения в основном продукте надо очень вдумчиво.

Как это делаем мы

Мы выпустили на рынок два тиражируемых продукта: ECM (или в более привычных терминах, систему электронного документооборота, СЭД) ТЕЗИС и систему для автоматизации бизнеса такси Sherlock. С самого начала было очевидно: для того, чтобы поставить конкретному клиенту максимально удобную систему, потребуются доработки продукта, и следовательно в основе продукта должна лежать легко расширяемая архитектура.

Начиная работу над новым расширением, часто мы даже не предполагали, в какого «монстра» (в хорошем смысле слова) этот проект может перерасти. Обычное явление — когда то, что начиналось как небольшая кастомизация, заканчивается практически полностью переписанными бизнес-процессами и дополнительной логикой на доброй половине экранов. Вдобавок продукт может расшириться новой функциональностью, вполне достаточной для самостоятельной системы. Как пример — в проекте-расширении ТЕЗИС для крупной распределенной компании появилась автоматизация деятельности казначейства, оценки эффективности работы сотрудников и еще несколько непростых модулей.

Разнообразие требований, их объем и непредсказуемость не позволяли использовать ни один из способов, описанных выше. Вдобавок ко всему, версии продуктов выходят довольно регулярно. Это делает обязательным требованием максимальную легкость перевода проекта-расширения на новую версию продукта.

Как же мы решаем проблему создания и поддержки расширений?

Наш проект-расширение

Большинство проектов нашей компании созданы с помощью платформы CUBA. Мы уже писали о ней в одной из прошлых статей. Для того, чтобы понять, как организованы проекты-расширения, сначала нужно разобраться с устройством самой платформы.

• cuba — ядро приложения, содержит в себе всю инфраструктуру, средства для организации бизнес-логики, библиотеку визуальных компонентов, подсистему безопасности и пр.
• reports — подсистема генерации отчетов
• fts — подсистема полнотекстового поиска
• charts — подсистема вывода диаграмм
• workflow — подсистема управления бизнес-процессами
• ccpayments — подсистема работы с кредитными картами

При создании нового проекта, в его скрипте сборки прописываются зависимости от тех базовых модулей платформы, функциональность которых необходима. После этого, используя сущности, экраны и сервисы подключенных модулей, мы начинаем реализовывать проект. Физически модули платформы — это jar файлы, а установленный на сервере проект — обычное Java веб-приложение.

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

Теперь внутри проекта-расширения можно создавать новые объекты доменной модели, описывать новый пользовательский интерфейс как в самом обычном проекте на платформе CUBA. Весь функционал ниже-лежащих модулей разработчику по прежнему доступен.

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

• вы указываете новую версию продукта в скриптах сборки и пересобираете расширение;
• если в расширении использовался только стабильный API продукта, то на этом все — запускаете свой расширенный продукт и вперед;
• если в продукте произошли значительные изменения в тех точках, которые вы расширяли, то может потребоваться изменение кода расширения. Как правило, это происходит нечасто, и локализовать проблему просто. Багфикс-релизы продуктов всегда сохраняют совместимость с расширениями.

Добавление нового атрибута в сущность базового продукта

Определим для себя задачу: в сущность User базового продукта необходимо добавить поле для хранения адреса. Подобные требования, пожалуй, самые распространенные среди наших заказчиков. Сразу скажем, что платформа поддерживает модель динамических атрибутов, о которых писалось выше, но на практике этот вариант используется редко — скорость выборки данных и легкость построения отчетов практически всегда оказываются важным требованием.
Собственно об альтернативном способе добавления атрибута. В качестве ORM платформой используется OpenJPA. Объявление сущности в продукте выглядит следующим образом:

Как видите, это стандартное для JPA описание сущности и маппинга на таблицу и колонки БД.

Создаем наследника сущности в проекте-расширении:

Механизм наследования стандартен для OpenJPA за исключением аннотации @Extends , которая и представляет наибольший интерес. Именно она объявляет, что класс ExtUser будет повсеместно использоваться вместо класса User.

Теперь все операции создания сущности User будут создавать экземпляр расширенной сущности:

Операции извлечения данных из БД также вернут экземпляры новой сущности. Например, в базовом продукте объявлен сервис поиска пользователей по имени, возвращающий результат следующего JPQL запроса:

Без аннотации @Extends мы имели бы на выходе коллекцию объектов User , и для получения адреса из ExtUser пришлось бы повторно перечитать из базы результат предыдущего запроса. Но используя информацию о переопределении, которую предоставляет аннотация @Extends , механизмы платформы произведут предварительную трансформацию запроса и вернут нам коллекцию объектов расширенной сущности ExtUser . Более того, если какие-то другие сущности имели ссылки на User , то при подключении расширения эти ссылки будут возвращать объекты типа ExtUser , без какого-либо изменения исходного кода.

Сущность переопределена. Теперь хорошо бы отобразить новое поле пользователю.

Экран платформы представляет собой связку XML + Java. XML декларативно описывает UI, Java-контроллер определяет реакцию на события. Понятно, что с переопределением Java-контроллера особых проблем не возникнет, а вот с расширением XML чуть сложнее. Вернемся к предыдущему примеру с добавлением поля address в сущность User .
Описание разметки простейшего экрана выглядит так:

Видим ссылку на контроллер экрана UserEditor, объявление источника данных (datasource), компонента fieldGroup, отображающего поля сущности, и фрейм со стандартными действиями “ОК” и “Отмена” (windowActions).

Совсем не хочется дублировать код базового экрана в проекте-расширении, поэтому мы добавили в платформу возможность наследования XML-дескрипторов экранов. Вот так выглядит наследник экрана из базового проекта:

В экране-наследнике указывается предок (атрибут extends) и описываются лишь те компоненты, которые должны быть добавлены в базовый экран либо переопределены в нем. Остается лишь объявить экран в конфигурационном файле с идентификатором базового экрана:

Переопределение бизнес-логики

Что касается переопределения функциональности, то здесь все достаточно тривиально. Инфраструктура платформы реализована на Spring. Соответственно и слой сервисов с бизнес логикой — это управляемые спрингом бины. Возможностей расширения, предоставляемых фреймворком, оказывается более чем достаточно для переопределения нужной бизнес-логики. Чтобы наглядно это продемонстрировать, снова небольшой пример. Допустим, на среднем слое в базовом продукте имеется компонент, выполняющий расчет цены:

Для того, чтобы в проекте-расширении заменить алгоритм расчета цены мы делаем 2 простых шага:

Создаем наследника переопределяемого компонента:

Регистрируем класс в конфигурационном файле Spring с идентификатором бина из базового продукта:

Теперь контейнер Spring будет всегда возвращать нам экземпляр ExtPriceCalculator.

Переопределение темы

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

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

Для реализации веб-UI нами был выбран популярный фреймворк Vaadin. Vaadin позволяет описывать темы на SCSS. Описание стилей для новой темы на SCSS само по себе в разы приятнее, чем на чистом CSS. Мы сделали процесс создания темы еще менее трудоемким, вынеся множество параметров в переменные.

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

В проекте расширении разработчику доступна возможность подключения новых визуальных компонентов. Большое количество готовых компонентов имеется в репозитории аддонов Vaadin. Если нужного компонента там не нашлось, то можно написать его самому.

Примеры различных визуальных тем:

Заключение

Если наш подход показался вам интересным, то можете попробовать платформу CUBA сами. Создавая продукт на платформе, вы автоматически получаете возможность кастомизировать его описанным способом. Всегда рады отзывам и комментариям!

Что такое кастомизация в программировании

Курс предназначен для базовой подготовки администраторов сайтов, созданных на "1С-Битрикс: Управление сайтом". Изучив курс, вы освоите основные методы администрирования системы, а также пополните знания по темам, изученным в курсе Контент-менеджер.

Если вы добросовестно изучите курс, то научитесь:

• управлять доступом к системе, сайтами, пользователями, группами пользователей;
• работать с инструментами системы;
• использовать возможности интерфейса по управлению системой;
• работать с модулями «1С-Битрикс: Управление сайтом», связанными с оптимизацией и безопасностью работы сайта;
• выполнять работу по конфигурированию веб-системы для оптимальной работы.

Если вам предстоит самостоятельная установка системы или перенос сайта на хостинг, то без курса Установка и настройка Курс Установка и настройка предназначен для специалистов устанавливающих «1С-Битрикс: Управление сайтом» или «Битрикс24 в коробке».

Начальные требования

Необходимый минимум знаний для изучения курса:

• базовые навыки компьютерной грамотности и навыки работы с ОС Windows;
• базовые знания по HTML, WWW и организации доступа к веб-серверу;
• знание системы в рамках курса Контент-менеджер Мы считаем, что вы этот курс уже прошли и знаете многое о Битриксе. Поэтому подсказок во всплывающих окнах будет намного меньше, чем в курсе Контент-менеджер. , чтобы банально не путаться в интерфейсе.

Неплохо было бы иметь базовые навыки установки и администрирования *nix-систем и основы Баз Данных.

У нас часто спрашивают, сколько нужно заплатить

Курс полностью бесплатен. Изучение курса, прохождение итоговых тестов и получение сертификатов — ничего из этого оплачивать не нужно.

Ещё у нас есть Академия 1С-Битрикс, где можно обучиться на платной основе на курсах нашей компании либо наших партнёров.

Баллы опыта

В конце каждого урока есть кнопка Прочитано! . При клике на неё в Вашу итоговую таблицу опыта добавляется то количество баллов, которое указано в прочитанном После нажатия кнопки Прочитано! появится
окно подтверждения:

уроке.

Периодически мы заново оцениваем сложность уроков, увеличивая/уменьшая число баллов, добавляем новые уроки. Поэтому итоговое количество баллов курса и количество набранных вами баллов могут различаться между собой. Набранные вами баллы, в отличие от суммы баллов курса, не пересчитываются. Не переживайте!
Отличный результат — это если общее число набранных вами баллов отличается от максимального на несколько процентов.

Тесты и сертификат

После изучения курса пройдите тесты на сертификацию. При успешной сдаче последовательности тестов на странице Моё обучение вы увидите результат обучения и там же — ваш сертификат в формате PDF.

Иконка успешно сданного вами курса отображается в вашем профиле на Freelance, если вы укажите ссылку на ваш профиль на сайте компании 1С-Битрикс.

Также Вы можете поделиться ссылкой на страницу со своими сертификатами. Для этого на странице Моё обучение отметьте опцию Разрешить публичный доступ к резюме студента и скопируйте ссылку на страницу резюме . Страница с Вашим резюме будет доступна всем, кому Вы отправите ссылку на неё.

Комментарии к урокам

На каждой странице курса авторизованный на сайте посетитель может дать комментарий к содержимому страницы. Комментарий — не форум, там не ведётся обсуждений или разъяснений. Это инструмент для сообщений нам об ошибках, неточностях. Для отправки комментария воспользуйтесь расположенной в правом нижнем углу окна браузера кнопкой:

Для преподавания офлайн

Если данный курс берётся в качестве основы для офлайнового преподавания, то рекомендуемая продолжительность: 3 дня (24 академических часа).

Если нет интернета

Скачать материалы курса в формате EPUB. Файлы формата EPUB Чем открыть файл на
Android:
EPUB Reader
CoolReader
FBReader
Moon+ Reader
eBoox

iPhone:
FBReader
CoolReader
iBook
Bookmate

Windows:
Calibre
FBReader
Icecream Ebook Reader
Плагины для браузеров:
EpuBReader – для Firefox
Readium – для Google Chrome

iOS
Marvin for iOS
ShortBook

Linux:
Calibre
FBReader
Cool Reader
Okular обновляются периодически, поэтому возможно некоторое отставание их от онлайновой версии курса. Версия файла — от 06.04.2023.

Кастомизации¶

Кастомизация — адаптация антидетекта под подмену конкретной реализации того или иного вида отпечатка.

Кастомизация состоит из нескольких частей:

• сбор сэмплов-образцов данных с реальных браузеров (точно таким же кодом как на целевом сайте)
• сэмплы-образцы данных собранные с реальных браузеров
• механизм подмены данных при посещении целевого сайта

Кастомизации могут быть заточены под конкретные сайты (на пример под paypal.com) и массовые, те которые работают на тысячах сайтах.

Как было сказано выше, существуют публичные javascript библиотеки для организации браузерного фингерпринтинга. Эти библиотеки используются на тысячах сайтах. И кастомизации для этих библиотек включены в каждый профиль по дефолту. Т.е. при покупке профиля дополнительно ничего не нужно докупать.

Сообщение о том, что кастомизация/сэмплы не найдены¶

В процессе работы Вы можете встречать сообщение о том, что Che browser не смог найти кастомизацию или сэмплы для подмены canvas/audio фингерпринтов.

Это может свидетельствовать о следующем:

• на сайте используется уникальное решение для сбора фингерпринта и требуется разработка кастомизации. О разработке кастомизаций читайте ниже.
• Вы забыли приобрести кастомизацию для данного домена в момент покупки профиля. При учете того, что под данный домен уже реализована кастомизация и доступна для приобретения. Пожалуйста проверьте приобретена ли требуемая кастомизация для используемого профиля. Посмотреть это можно в окне Settings — настройки профиля. В поле Customizations рядом с названием требуемого домена должна стоять галочка ✔
• установленный в системе google chrome не поддерживает WebGL1 или WebGL2 Прочитайте пункт документации Тестирование поддержки Web GL
• иногда бывает ложное срабатывание. На сайте используются какие то методы которые так же могут используются при сборе фингерпринта, но совершенно в других целях. На пример для проигрывания звука или отрисовки картинок на canvas.

Так же, иногда после обновления ОС может перестать работать web gl2 и в профилях с кастомизацией на сайтах может начать отображаться, что Че не смог подобрать семплы. В таких ситуациях проверьте работоспособность web gl2. Как это сделать описано в разделе Тестирование поддержки Web GL

В любом случае Вы можете просто закрыть сообщение. А работать или не работать дальше зависит от выше описанных пунктов.

bestbuy.com¶

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

facebook.com¶

Facebook полностью отказался от canvas фингерпринта. И очень активно использует замеры времени для фингерпринта браузера и пользователя. По этой причине рекомендуем использовать Time shifting — эта технология позволит влиять на фингерпринты основанные на замерах времени.

paypal.com¶

Укажите данную кастомизацию при покупке профиля если планируете взаимодействовать с paypal.com или ebay.com. В самое ближайшее время будет проведен аудит кода paypal и внесены коррективы, если они требуются.

Так же хотелось бы отметить, что в ближайших релизах будет доработан функционал для взаимодействия с ebay.com. Т.к. было выявлено еще несколько механизмов при помощи которых ebay.com персонализирует Ваш компьютер.

amazon.com¶

Фингерпринт в амазон реализован не совсем стандартным образом. Общая схема canvas фингерпринта выглядит так:

• Первый этап: классический canvas фингерпринт. На canvas рисутся различные геометрические фигуры и накладывается статический текст.
• Второй этап: на картинку из первого этапа накладывается текст с email адресом логина
• Третий этап: амазон получает сырые данные из CanvasRenderingContext2D и строит по этим данных гистограмму

Таким образом амазон отслеживает изменение железа и привязку акаунта к данному железу. И исходя из выше описанной схемы следует, то что нельзя просто собрать один раз данные с реального браузера. Т.к. при сборе данных наша система еще не знает какой email Вы будете использовать для логина. По этой причине был реализован много ступенчатый сбор данных. Во время сбора профиля мы собираем canvas фингерпринт из первого этапа. Далее, после того как Вы приобрели профиль Вам нужно указать какие email адреса будут использоваться в этом профиле при входе в амазон. После этого сборщик профилей отслеживает появление подходящего браузера и собирает данные из второго и третьего этапов.

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

И так, для работы с кастомизацией под амазон Вам нужно выполнить следущие действия

• приобрести профиль с кастомизацией под amazon.com
• в настройках профиля (в блоке Customization) найти бэдж в котором будет написано amazon.com
• кликнуть на иконку, как показано на картинке ниже
• в открывшемся модальном окне ввести список email адресов под которыми Вы планируете логиниться в amazon.com. Каждый email должен располагаться на новой строке.
• дождаться когда сборщик профилей до собирет данные с подходящего браузера
• после того как в настройках профиля исчезнет плашка с информацией о том, что еще не все сэмплы собраны можно приступать к работе

Обязательно дождитесь когда эта плашка исчезнет и только после этого начинайте работу.

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

Заказать разработку кастомизации¶

Вы всегда можете обратиться с вопросом о разработке кастомизации под интересующий Вас сайт.

Все условия и цены обсуждаются в индивидуальном порядке. Заявки под кастомизации оставлять нашей поддержке.