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

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

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

Зарабатывайте на поддержке, не на покупке

Покупка, конечно, может быть платной, в идеальном мире это должно было бы быть 100? суммой заработка от готовых решений (на то они и готовые), но покупатели практически всегда будут не программисты и не будут иметь программиста в штате. Это та экосистема, которую создаёт cms, и в особенности Битрикс.

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

Хорошим решением может быть уменьшение цены модуля, даже до нуля, несмотря на то что вы хотите заработать с продаж, но ясно объявить цену часа работ. С увеличением автономности установки можно увеличивать и цену покупки. Но автономность никогда не будет 100%, потому что сайты далеко не всегда делаются по гайдам Битрикса.

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

Давайте возможность переустановить модуль

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

Проблема в том, что модулю нужно хранить данные в базе данных или файлах.

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

Давать выбор при удалении модуля стирать ли данные или нет — лучший выход в данной ситуации, несмотря на то что Битрикс обычно говорит, про полное стирание следов модуля при деинсталляции.

Много функционала внутри одного модуля или много маленьких модулей?

Объясню проблему на примере модуля комментариев.

Вот вы сделали такой продукт (модуль комментариев) и выпустили его в Маркетплейс. С его помощью можно писать комментарии к товарам. А возможно даже удалять, редактировать и отвечать на чужие.

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

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

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

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

Техподдержка клиентов

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

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

Отчасти так складывается из-за политики техподдержки Битрикса. Они отвечают всем, но если увидят чужой код, сразу умывают руки. Например, если ваш модуль использует какое-либо событие ядра (а он скорее всего использует), то тех. поддержка быстренько переведёт проблему клиента на вас, если это событие вызывается где-то в сценарии ошибки. Например, ошибка происходит при создании заказа, а у модуля есть обработчик события получения цены товара. И их можно понять. Кому бы захотелось бесплатно разбираться в чужом коде?

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

Учитывайте это при ценообразовании и планировании трудозатрат.

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

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

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

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

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

Дополнительный плюс такого подхода — отсутствие необходимости клиента в программисте.

Хранение javascript кода

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

my.component/
- class.php
- component.php
- .parameters.php
- .description.php
- templates/
  - .default/
    - .parameters.php
    - result_modifier.php
    - template.php
    - style.css
    - script.js
    - component_epilog.php
    - lang/
      - ru/
        
        .parameters.php
        
        result_modifier.php
        
        template.php
        
        component_epilog.php
- lang/
  - ru/
    - class.php
    - component.php
    - .parameters.php
    - .description.php

А вот как лучше её переделать при наличии аякс вызовов или логики внутри js:

my.component/
- class.php
- component.php
- script.js
- .parameters.php
- .description.php
- templates/
  - .default/
    - .parameters.php
    - result_modifier.php
    - template.php
    - style.css
    - script.js
    - component_epilog.php
    - lang/
      - ru/
        
        .parameters.php
        
        result_modifier.php
        
        template.php
        
        component_epilog.php
- lang/
  - ru/
    - class.php
    - component.php
    - .parameters.php
    - .description.php

То есть выносить важный js в компонент, а не держать его в шаблоне. В последнем должна дёргаться лишь API и использоваться обработчики повешенные на элементы.

Ну и спасибо, КО. Общий для модуля js можно вынести в папку самого модуля.

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

Jquery и javascript-библиотека Битрикса

Мало кому хочется писать аякс вызовы или делать обработку наведения на чистом js, поэтому многие тянутся к jQuery, которую сейчас сложно не встретить на случайном сайте. Также некоторые знают, про js-библиотеку Битрикса, которая тоже предоставляет какие-то обёртки для удобства работы.

Но реальность такова, что js-библиотека самой cms толком бессмысленная, да и к тому же иногда вредная, например, потому что почему-то не работает с композитом.

А с jQuery проблема в том, что она почти везде подключена, но всё же не везде. А если и подключена, то может быть слишком старая версия.

Мы советуем писать или на ваниле или сделать настройку компонента “Подключать ли jQuery?”, чтобы можно было тонко управлять этим моментом и отключать, где потребуется. Последний, кстати, довольно популярный способ среди разработчиков модулей.

Как можно более уникальные классы css, как можно больше правил для селектора

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

Но наличие (и популярность) “сайтов-конструкторов” заставляют прописывать чуть ли не каждый параметр для каждого селектора явно, даже прописывать “content: ‘’” для псевдоэлементов, если вы их не используете. Более того будьте готовы к большому числу использований “!important” в вашем css.

Всегда берите доступы фтп, если нужно править код

Вы можете знать, что в админке Битрикса есть встроенный редактор файлов, так что код можно править через браузер. Но опыт показал, что если для починки или анализа проблемы вам нужно править хоть какой-то файл на сайте, лучше сразу брать фтп, так как можно задеть какой-нибудь код, который вызывается в init.php (а это часто) и сайт сразу упадёт без возможности откатить изменения через админку, которая тоже не будет работать.

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

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

Покупатели почти всегда бизнес

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

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

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

Плохое окружение

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

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

А вот код самого сайта это уже другое дело. Здесь может быть ужасный код, так как многие сайты делались довольно давно, многие делались плохими программистами, так как порог вхождения в сам php довольно низкий.

А некоторые сайты наоборот делались “хорошими” программистами, но пришедшими с фреймворков или других систем (иногда самописных) и даже не старавшимися понять Битрикс. Видимо из-за гордыни. Кстати, есть и другой “конец” кода, когда от Битрикса остаётся только название и админка, и большая часть функционала делается в обход модулей Битрикса, а соответственно и событий и таблиц БД.

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

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

Нужно ли отлично знать D7?

Уже довольно давно Битрикс выпустил новое ядро своей системы, в котором было переписано почти всё, появилось множество новых фишек, классы немного унифицировались и всё стало ООП. Но мы решили не писать наши решения на чистом d7.

Делаем мы так из-за распространения технологии. Несмотря на то что релиз состоялся довольно давно, хоть и изредка, но мы встречаем сайты на старом ядре. Таких клиентов мало и с ними скорее всего будет много проблем (потому что они будут обновляться и всё полетит), поэтому ими можно пренебречь в размышлениях.

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

А вот с поддержкой старого ядра мы ещё не встречали ни одной проблемы.

Вместо заключения

Конечно, некоторые пункты звучат как “чтобы писать модули, вы должны их писать”. Но все эти моменты лучше осознавать и держать в голове, чтобы избегать ошибок, набитых опытом и не набирать его самостоятельно.

Мы собираемся пополнять статью по мере наработки опыта, чтобы использовать её как шпаргалку внутри компании.

И в дополнение ссылка на официальную документацию Битрикса о разработке модулей.

Моменты в разработке и продаже модулей Битрикс