Здесь будет рассказано не столько о технических аспектах расширения Битрикса (одна из причин почему его не любят), а скорее о моментах связанных с экосистемой Битрикса (другая причина почему его не любят), хотя технические вещи тоже будут, но в значительно меньшей степени, чтобы не повторять документацию. В этой статье не будет субъективной оценки cms или компании, только сухие факты и мысли, которые помогут зарабатывать на модулях. Мы перечислим те моменты, которым нас научил наш собственный опыт продажи модулей через Маркетплейс. Некоторые из них кажутся очень очевидными и общими, другие же наоборот являются очень специфичными для платформы, но они все относятся к работе над модулями Битрикс, и поэтому включены в список. Поэтому задачи интеграции функционала или правок в дизайне часто ложатся на самих создателей. А поскольку время программистов дорогое, вам придётся брать деньги с клиента поверх покупки, а клиенту платить дважды. Хорошим решением может быть уменьшение цены модуля, даже до нуля, несмотря на то что вы хотите заработать с продаж, но ясно объявить цену часа работ. С увеличением автономности установки можно увеличивать и цену покупки. Но автономность никогда не будет 100%, потому что сайты далеко не всегда делаются по гайдам Битрикса. Совет, конечно же, актуален, только если вы собираетесь зарабатывать на модулях. Иногда нужно просто удалить модуль и поставить заново. Может быть миллион ситуаций, когда что-то пошло не так: модуль не скачался полностью, как-то криво встали обновления, кто-то поменял исходный код вашего решения на сайте покупателя, ... Проблема в том, что модулю нужно хранить данные в базе данных или файлах. При полном удалении модуля, конечно, стоит замести все следы его присутствия, иначе, кстати, можно и модерацию не пройти. Но при перестановке наоборот нужно как-то сохранить всё, чтобы пользователю не нужно было заново всё заполнять и настраивать. Давать выбор при удалении модуля стирать ли данные или нет — лучший выход в данной ситуации, несмотря на то что Битрикс обычно говорит, про полное стирание следов модуля при деинсталляции. Объясню проблему на примере модуля комментариев. Вот вы сделали такой продукт (модуль комментариев) и выпустили его в Маркетплейс. С его помощью можно писать комментарии к товарам. А возможно даже удалять, редактировать и отвечать на чужие. Но вот один покупатель захотел всё то же самое, что есть у вас, и даже в том же дизайне, но чтобы это были полноценные отзывы: с рейтингом, фотографиями, полями достоинств и недостатков. Делать второй модуль или расширить функционал первого? Может показаться, что вопрос сугубо индивидуальный, но если посмотреть всю экосистему Битрикса: дорогая cms со множеством функционала из коробки, типовые сайты и даже сайты-конструкторы очень популярны в магазине, цены на разработку довольно большие, то можно выявить тенденцию, что избыточность и цены не так важны покупателям. Также стоит учитывать, что покупатели зачастую являются бизнесом, следовательно продажи происходят довольно долго, а цены не имеют такого большого значения как при работе с физ. лицами. Плюс мы общались напрямую с клиентами и множество из них отвечало, что они купили какой-то дорогой продукт из-за какой одной конкретной фишки. Например, покупка сайта-конструктора за несколько десятков тысяч рублей (причём с ужасными отзывами) произошла, потому что там понравились баннеры. Да и вы наверняка слышали от своих клиентов рассказы, почему они хотят Битрикс как таковой, и слышали примерно такие же ответы. Вот вы выпустили хороший модуль с чистым и легкочитаемым кодом, написали документации и инструкции на все случаи жизни, модуль выполняет только свои конкретные и явно заявленные функции, сам ставится — скачивай и используй. Но в реальной жизни если появится какая-нибудь проблема на сайте, в которой хоть как-то задействован ваш модуль в первую очередь будут писать вам. Кстати, проблемой с вашим модулем будет считаться также любая проблема, которая произошла на сайте покупателя после установки вашего модуля и до установки другого модуля или больших изменений дизайна. Даже если у вас модуль обратного звонка и его ставили 4 месяца назад, а вчера отвалилась выгрузка в 1С, то всё равно могут написать вам. Отчасти так складывается из-за политики техподдержки Битрикса. Они отвечают всем, но если увидят чужой код, сразу умывают руки. Например, если ваш модуль использует какое-либо событие ядра (а он скорее всего использует), то тех. поддержка быстренько переведёт проблему клиента на вас, если это событие вызывается где-то в сценарии ошибки. Например, ошибка происходит при создании заказа, а у модуля есть обработчик события получения цены товара. И их можно понять. Кому бы захотелось бесплатно разбираться в чужом коде? И потом, почти никто не будет читать ваши инструкции или заходить на вашу интуитивнопонятную страницу настроек, в 80% случаев сразу будут писать вам в техподдержку. Наверное, так в любой сфере деятельности. Но нам кажется, что масла в огонь подливает огромная админпанель Битрикса и необходимость прочитать несколько курсов, чтобы уметь ей пользоваться. Учитывайте это при ценообразовании и планировании трудозатрат. Все сайты разные и, соответственно, им бывают нужны разные вещи от ваших компонентов, например, другие тексты у надписей, дизайн, набор элементов. В Битриксе можно копировать шаблоны компонентов и менять их на свой лад. Это нормальная практика. Но опыт показал, что лучше остерегать пользователей от таких действий. Ведь если возникнет ошибка в шаблоне или вы просто улучшите его, добавите новые фишки, нельзя будет обновить шаблон у клиента, так как он кастомизирован. Так что вы даже не сможете помочь клиенту с его ошибкой в отображении вашего же функционала. Поэтому хорошим решением будет предоставлять как можно больше настроек подключения компонента, чтобы все необходимые кастомизации можно было проводить без правки его кода, а просто “крутя” настройки. Дополнительный плюс такого подхода — отсутствие необходимости клиента в программисте. А вот как лучше её переделать при наличии аякс вызовов или логики внутри js: То есть выносить важный js в компонент, а не держать его в шаблоне. В последнем должна дёргаться лишь API и использоваться обработчики повешенные на элементы. Ну и спасибо, КО. Общий для модуля js можно вынести в папку самого модуля. Смысл этого в том, что всё что находится в папке шаблона компонента относится лишь к отображению, а не к логике. Соответственно, при кастомизации шаблона, копируется вся папка, включая ваш script.js. И появляются те же проблемы с поддержкой и обновлениями, как в предыдущем пункте, но с предложенной структурой можно значительно уменьшить их. Но реальность такова, что js-библиотека самой cms толком бессмысленная, да и к тому же иногда вредная, например, потому что почему-то не работает с композитом. А с jQuery проблема в том, что она почти везде подключена, но всё же не везде. А если и подключена, то может быть слишком старая версия. Мы советуем писать или на ваниле или сделать настройку компонента “Подключать ли jQuery?”, чтобы можно было тонко управлять этим моментом и отключать, где потребуется. Последний, кстати, довольно популярный способ среди разработчиков модулей. Но наличие (и популярность) “сайтов-конструкторов” заставляют прописывать чуть ли не каждый параметр для каждого селектора явно, даже прописывать “content: ‘’” для псевдоэлементов, если вы их не используете. Более того будьте готовы к большому числу использований “!important” в вашем css. Плюс некоторые разработчики умудряются сделать страницу так, что она падает, просто если посмотреть её код через Битрикс. Причины возникновения такого поведения нам до сих пор не ясны, но такие случаи действительно бывают. Следовательно править файлы через браузер довольно рискованное занятие, если вы не можете заново поднять сайт за минуту. Нам кажется, что преобладание официального бизнеса в Битриксе будет практически в любых срезах клиентов, как минимум потому что он не дешёвый — на нём очень редко будут делать просто блог. Для нас как для продавцов это означает большие суммы продаж за единицу товара, но более долгий цикл покупки и мучения с бухгалтерами клиентов. Что бы не говорили, за код ядра можно не беспокоиться. Он протестирован десятки тысяч раз, не меняется от сайта к сайту, обновления всегда имеют обратную совместимость. Да и техподдержка может помочь с ним бесплатно. А вот код самого сайта это уже другое дело. Здесь может быть ужасный код, так как многие сайты делались довольно давно, многие делались плохими программистами, так как порог вхождения в сам php довольно низкий. А некоторые сайты наоборот делались “хорошими” программистами, но пришедшими с фреймворков или других систем (иногда самописных) и даже не старавшимися понять Битрикс. Видимо из-за гордыни. Кстати, есть и другой “конец” кода, когда от Битрикса остаётся только название и админка, и большая часть функционала делается в обход модулей Битрикса, а соответственно и событий и таблиц БД. Плюс модули других разработчиков могут перекрывать ваш модуль своими обработчиками. Всё это несёт проблемы, в основном в поддержке. Также будьте готовы, что ваш модуль может просто не установиться на сайт клиента, установиться не полностью или не заработать, а вам придётся долго дебажить сайт и объяснять клиенту, что ему придётся заплатить за доп. работы на сайте, потому что иначе ничего работать не будет. Делаем мы так из-за распространения технологии. Несмотря на то что релиз состоялся довольно давно, хоть и изредка, но мы встречаем сайты на старом ядре. Таких клиентов мало и с ними скорее всего будет много проблем (потому что они будут обновляться и всё полетит), поэтому ими можно пренебречь в размышлениях. Для нас ключевым фактором стали недостаточность документации и то что технология мало “обкатана”, что означает, что быстрый поиск решения в интернете вряд ли даст решение проблемы. А вот с поддержкой старого ядра мы ещё не встречали ни одной проблемы. Мы собираемся пополнять статью по мере наработки опыта, чтобы использовать её как шпаргалку внутри компании. Программист