За все время своей работы с Битрикс мне довелось поработать с очень большим количеством проектов, которые кто-то разрабатывал до меня. Тут и мелкие доработки, фикс различных багов и ошибки работы логики, редизайн сайта и глобальные изменения существующего функционала. И, как и любой другой разработчик, я терпеть не могу разгребать чужой мусор, костыли и «временные» заплатки, которые на деле помнят еще 8 редакцию продукта.
Здесь я постараюсь не акцентировать внимание на стандартных «worst practice» при программировании на PHP, типа наплевательского отношения к выборам имен переменных и функций, излишних запросов к БД в цикле, отсутствия проверок пользовательских данных в формах, игнорирование комментариев и тому подобного. Я попытаюсь коснуться именно моментов, свойственных разработке на Битриксе, которые в последствии позволят избежать негодования и проклятий в ваш адрес от программиста, которому выпало сопровождать ваш код. И да, нередко этим программистом будете оказываться вы сами через год, или более, когда уже совершенно забудете, зачем вы вставляли сюда тот или иной костыль.
«Пишите код так, как будто сопровождать его будет склонный к насилию психопат, который знает, где вы живёте» © Джон Ф. Вудс
Первое, и самое, на мой взгляд, важное - ради всего святого, используйте папку local . Это просто жизненно необходимо при использовании системы контроля версий — все, что вам нужно — добавить в исключения папку /bitrix/. Всё. Далее практически вся разработка ведется только в ней. Это заметно упрощает поиск нужных файлов и компонентов в последствии, помогает не засорять репозиторий лишними файлами, да и вообще — приводит дерево проекта в более опрятный, «человеческий» вид.
Не модифицируйте ядро . Даже если вы уверены, что оно не будет обновляться. Даже если так быстрее. Даже если вам лень. Забудьте эту мысль, как страшный сон. Если необходимо изменить логику работы стандартного компонента — перенесите его в новое пространство имен /local/components/modify/ и работайте с ним. То же самое касается модулей, гаджетов и activities бизнес-процессов.
Не засоряйте файл init.php . Объединяйте функции для работы с каким-то конкретным модулем или функционалом в класс, весь этот класс записывайте в отдельный файл, а в init.php просто подключайте эти файлы и прописывайте обработчики событий. Мне встречались файлы init.php по 500Kb, где в кашу были смешаны функции, определение констант, классы и инициализация обработчиков. Разумеется, когда приходилось разбираться в этих файлах, я сыпал проклятиями на своих предшественников.
Следующий пункт не касается случая разработки готовых решений для Marketplace, когда целью ставится сделать максимально настраиваемый функционал из публичной части для конечного потребителя. Если вы работаете над конкретным проектом, по конкретному ТЗ — не стоит пытаться сделать унифицированный шаблон для компонента на все случаи жизни . Лично я придерживаюсь философии — лучше несколько простых шаблонов, использующихся для разных целей, чем один универсальный, но в котором сам черт потом ногу сломит. Разумеется, в каждом конкретном случае нужно отталкиваться от того, что есть — техзадание, варианты реализации и тому подобное, но забывать про «Бритву Оккама» все-таки не стоит. Как пример приведу один проект лизинговой компании, который мне довелось править. Сам проект, конечно, был реализован ужасно, на настоящий ужас был в страницах раздела каталога услуг. У каждого из пяти разделов была собственная верстка, на которых отличалось как положение блоков на странице, так и в принципе наличие некоторых из них. И для всех пяти страниц использовался один шаблон с кучей if-else, дублированием вызовов компонентов, подключением стилей и скриптов, которые, к тому же, периодически конфликтовали друг с другом. Как итог — огромный файл, в котором разобраться «без поллитры» было смерти подобно. Хотя, казалось бы, что мешало сделать 5 разных шаблонов и не создавать трудностей на ровном месте?
Используйте API . Не изобретайте велосипеды там, где это не нужно. Юзайте документацию — весь продукт довольно хорошо описан, а так же каждую функцию можно посмотреть детально на bxapi.ru.
Избегайте прямых запросов к базе . Это частный случай предыдущего пункта — используйте API. Необдуманные, незащищенные запросы могут привести к порче, утере или даже к компрометации данных.
Не используйте компоненты с ЧПУ из корня сайта . Последствия, как правило, довольно печальны, так как ЧПУ использует файл обработчика адресов, попытка использовать его из корня легко ломает вам адресацию других компонентов, а так же 404 страницы. Ничего страшного не будет, если статьи у вас будут адресоваться относительно папки /articles/, а товары относительно /catalog/.
Подключайте css и js с помощью API. До сих пор повсеместно встречаю подключение скриптов и стилей с помощью html-тегов. Используйте объект класса \Bitrix\Main\Page\Asset и функции addJs () и addCss (). Это позволит объединять файлы и, в последствии, кешировать их одним нажатием чекбокса в настройках главного модуля
Ну и напоследок, ошибка касается не только Битрикса, но уж больно часто я стал встречать проблемы, связанные с ней. Проверяйте на пустоту массив с результатами выборки . Как пример, последний раз встретился с данной проблемой при работе с одним интернет-магазином. Жалоба: страницы иногда грузятся по 16 секунд. С чем связано — не ясно. Методом проб и ошибок выяснил, что страницы грузятся неприлично долго только тогда, когда корзина пустая. Казалось, с чего бы? Как выяснилось, у корзины при наведении появлялось всплывающее окно, в котором отображались изображения товара, положенного в корзину. Ну что сделал предыдущий разработчик? Взял результат работы компонента «маленькая корзина» и в файле result_modifier.php сделал вызов GetList () товаров для выборки изображений с фильтром из массива ID товаров, потом из результатов выборки в массив соответствующего товара добавлял src изображения. В итоге, когда товаров в корзине не было, фильтр уходил пустой, и в выборку попадал ВЕСЬ каталог товаров. Ну, а дальше цикл по каждому и… имеем то, что имеем. Ясно, что на этапе разработки при тестовых 15 товарах это было незаметно, и проблемы возникли уже в боевых условиях. Хотя, казалось бы, чего стоило поставить проверку на empty ($arResult[«ITEMS»])…
На этом я заканчиваю свой личный топ «worst practice», касательно разработки на Битрикс. Если хоть кому-то данная информация поможет избежать ошибок в будущем и улучшить свой стиль разработки, значит это было не зря.
Периодически наша студия сталкивается с необходимостью переноса контента с одной платформы на другую. Говоря о переносе контента, мы имеем в виду массовый перенос, т. е. когда на новом сайте требуется разместить значительное количество информации со старого сайта - сотни, тысячи новостей, публикаций, статей, фотографий, видеоматериалов и т.п.
Что такое "управление контентом"? Это когда оператор в админке видит ровно те элементы управления, которые предполагаются для того или иного вида информации, при этом оператор совершает минимальный набор действий для достижения какой-то цели.
Например, существуют крупные учреждения, обладающие обширной территориальной сетью, которые регулярно публикуют новости. Вот при создании или редактировании такой новости у оператора должна быть возможность выбрать подобную привязку к территориальному отделению из некоего выпадающего списка, который не только содержит список таких отделений, но и сам обновляется, если появляются новые отделения.
Битрикс, заслуженно получая регулярные негативные отзывы, как о платформе для разработки, тем не менее вполне пригоден для создания информационных порталов. Админка Битрикса далеко не безгранична по своим возможностям, и не всегда совершенна по имеющемуся функционалу, но большинство требуемых функций там может быть реализовано с той или иной степенью приемлемости.
И если с возможностями организации информации в экосистеме Битрикса и возможностями управления этой информацией всё более или менее понятно, то процесс переноса всегда представляет собой определённые трудности. На самом деле это всегда индивидуальная задача, т.е. перенос контента проекта "А" на Битрикс и перенос контента проекта "Б" на Битрикс - это обычно две самостоятельные задачи.
Как же получается, что такая, казалось бы, типовая и повторяемая задача становится очень индивидуальной? Дело всегда в разнице исходных и требуемых форматов (в широком смысле слова). Палитра технических возможностей различных CMS по хранению и представлению идентичного контента слишком велика, чтобы это можно было решить единожды и навсегда. Ниже постараемся вкратце раскрыть ряд вопросов, с которыми неизбежно приходится сталкиваться при переносе контента с одной CMS на другую.
Текст
Текст - это не просто текст. Это, как правило, HTML разметка, причём часто еще и инлайн-стилизованная. Разные CMS используют разные текстовые редакторы, поэтому разметка в дополнение к главной своей части может содержать служебные данные в html-комментариях. Существенно ли это? Говоря о комментариях - они могут иметь несколько сотен строк и в несколько раз превышать объём самого текста. Соответственно, всю эту красота вы будете наблюдать в визуальном редакторе Битрикса. Если говорить уже о самом тексте и его стилизации - некоторая стилизация может быть признана полезной, а некоторая - неприемлемой относительно общего подхода, используемого на новом сайте. Поэтому, к сожалению, нельзя просто бездумно пройтись регуляркой и всё срезать, надо подходить выборочно.
Плагины
Типична ситуация, когда часть контента управляется с помощью некоторых плагинов к CMS. Текст может содержать в себе некоторые, скажем так, управляющие выражения, которые используются для вывода в этом месте другого контента. Код CMS при выводе контента сначала проверяет его на наличие таких выражений, и, если нужно, запускает сторонние механизмы, которые уже заменяют эти выражения новым контентом. Что это означает с точки зрения переноса данных? Что вы больше не можете просто взять и скопировать текст, т.к. Битрикс ничего не знает о том, что делать с такими управляющими выражениями. Вместо этого можно либо просто избавиться от них, естественно, утеряв соответствующую часть контента, либо подготовить эту часть контента таким образом, чтобы она не только технически могла быть импортирована в Битрикс, но и точно соответствовала структуре этого вида данных. Один из самых ярких примеров такой ситуации - фотогалереи внутри статей.
Картинки
Изображения с точки зрения управления контентом, могут быть разделены на 2 большие категории - те, которые являются частью текста и выводятся в потоке текста как его часть, и изображения, которые определены отдельно от текста и вывод которых задаётся вспомогательными механизмами. Эти категории требуют разных способом обработки и разных подходов в процессе подготовки импорта данных в Битрикс.
Например, одна из типичных ситуаций - имеем просто текст статьи в виде html разметки с инлайн-картинками. Необходимо сформировать данные для элемента инфоблока таким образом, чтобы подробной картинкой стало первое изображение, а остальные остались в потоке текста. Задачи, которые при этом возникают: необходимо вырезать разметку первой картинки, сформировать путь, пригодный для получения картинки (http-uri или путь в файловой системе), сформировать корректный путь к картинке для файла импорта, поместить картинку по этому пути; для инлайн-картинок нужно сформировать линки для получения картинок, разместить картинки там, где мы предполагаем их постоянное хранение, в тексте заменить исходные пути на новые.
Семантические URL
Использование ЧПУ URL для адресации - уже давно скорее общее правило, чем некий особый функционал для сайта. К сожалению, в настоящий момент Битрикс не поддерживает создания таких кодов во время импорта автоматически (по-крайней мере, нам этого не так и не удалось добиться), но это можно обойти использованием сторонних модулей для их генерирования уже после импорта данных. Однако, это не очень удобно с точки зрения организации процесса при массовом импорте, и, кроме того, вполне возможна ситуация, когда генерирование должно быть произведено с "тонкими настройками", на которые эти сторонние модули, разумеется, не рассчитаны (это может быть и генерирование исходя из конкретной части контента, и особый порядок учёта дубликатов). Поэтому выгоднее это делать на этапе подготовки данных.
Специализированные свойства инфоблоков
Админка Битрикса поддерживает создание дополнительных и пользовательских свойств инфоблоков, которые помогают наиболее подходящим способом управлять данными, этим можно и нужно активно пользоваться. То есть, если для публикации предусмотрена фотогалерея, как один из элементов этой публикации, разумно создавать отдельное множественное свойство, и в него импортировать необходимые картинки. Либо же создавать отдельный "галерейный" инфоблок и в статье ссылаться не него (точнее - на нужный элемент). Однако, с технической точки зрения, формирование правильной структуры в файле импорта для таких свойств - процедура не всегда "интуитивно" понятная и developer-friendly.
Как импортировать?
Битрикс поддерживает несколько способов импорта данных. Через программный API и через 2 вида формата файлов - csv или xml. Все эти способы имеют свои преимущества и недостатки. Так, с одной стороны, импорт через API кажется наиболее естественным решением - т. е. записываем напрямую и всё. Однако, де-факто это не самое лучшее решение с разных точек зрения. Во-первых, при большом объеме данных попыток импорта наверняка будет больше одной, т. к. будут обнаруживаться новые и новые кейсы, которые не были видны на первый взгляд. Каждая такая попытка импорта будет занимать существенное количество времени (пробовали импортировать большой xml на несколько тысяч элементов?). Для проверки результатов импорта необходимо каждый раз будет в админке путешествовать по разным элементам и исследовать значения их разных свойств и полей. В деле проверок GUI всегда больше мешает, чем помогает.
Для массового импорта более подходящим является формирование результатов в виде готового файла (при этом xml предпочтительнее, т.к. csv импорт крайне ограничен в возможностях). Во-первый, такой результат можно получать на любой машине локально, не на сервере, где развернут сайт. Во-вторых, результат преобразования данных (коим является сформированный файл импорта) может быть подвергнут анализу на пригодность любыми подходящими способами - начиная от банальных проверок регулярками и заканчивая валидацией по xsd схеме. Кроме того, такой способ позволяет полностью подготовить полностью готовый к импорту пакет (т.е. не только собственно файл импорта, но и все остальные сопутствующие файлы), но делать это поэтапно, по мере решения изначальных и возникающих в процессе задач.
Что делать?
Для решения описанных в этой статье задач в студии создан внутренний инструментарий, который позволяет достаточно оперативно и бережно перенести данные со старого сайта на новый, избежав при этом потерь информации, времени, денег и нервных клеток. При этом весь исторический контент будет управляться точно так же, как задумано на новом сайте.
В следующей статье мы расскажем о технических подробностях...
Если вам необходимо реализовать какой-то проект, вы можете создать группу, пригласить в нее только тех сотрудников, которые имеют отношение к этому проекту, поставить им задачи, загрузить необходимые файлы. Группы помогают сгруппировать все данные, задачи, файлы, сообщения, встречи в одном месте. Вы всегда сможете просмотреть какие действия, какие задачи были выполнены в той или иной группе.
В Битрикс24 есть группы и проекты. Основное отличие группы от проекта – в проекте можно задать сроки реализации проекта, сроки задач в проекте не могут выходить за рамки сроков проекта.
Поэтому если вам нужны конкретные сроки в проекте, то при создании группы вы можете выбрать тип группы - Проект . Если сроки не важны, то это может быть обычная рабочая группа.
Подробнее о создании группы или проекта можно прочитать .
2. Кто может создавать группы и проекты?
Каждый сотрудник может создавать группу или проект и приглашать в нее участников. Количество групп и проектов в Битрикс24 неограниченно на всех тарифах.
3. Как посмотреть все группы (проекты), которые есть на портале?
Все группы на портале может посмотреть сотрудник с правами администратора. Для этого нужно .
4. Как архивировать группу (проект)?
Для этого во вкладке группы Основное выбрать меню Действия и в нем пункт Редактировать группу (проект) . В открывшемся окне отметить Тип группы (проекта): Архивный .
Архивные группы и проекты не отображаются в общем списке групп. Найти их можно по фильтру Архивные либо с помощью поискового запроса.
Вернуть архивную группу (проект) в работу можно аналогичным способом – снять галочку с типа группы Архивная .
5. Как удалить группу?
Для удаления группы выберите во вкладке группы Основное пункт меню Действия > Удалить группу :
После клика откроется форма подтверждения удаления группы.
Если к группе (проекту) привязаны какие-то задачи, то нужно сначала открепить или удалить задачи, а потом уже можно будет удалить саму группу (проект).
6. Как удалить группу (проект), которая принадлежит уволенному сотруднику?
Удалить такую группу может администратор портала. Для этого нужно на странице Моя страница и далее в меню Действия выбрать пункт Удалить группу :
Если группа или проект еще нужны, то можно просто поменять владельца группы (руководителя проекта) через меню Действия : либо в Редактировании группы (проекта) , либо в Редактировании состава .
7. Можно ли запретить участникам группы (проекта) видеть друг друга?
Если вам необходимо разделить видимость сотрудников именно по группам, есть функция Экстранет (внешние пользователи) , которая доступна на коммерческих тарифных планах Битрикс24 . Этот инструмент позволяет работать с внешними сотрудниками, приглашать их в группы (проекты) и вести всю работу именно в рамках группы. При этом внутренние и внешние сотрудники будут видеть друг друга, только если являются участниками одной экстранет-группы (проекта).
При этом если у вас несколько экстранет-групп (проектов), то между собой участники не видят друг друга.
8. Как пригласить экстранет-пользователя в группу (проект)?
Пользователей можно пригласить как непосредственно при создании рабочей группы (проекта), так в любой момент после создания рабочей группы (проекта) на закладке Основное страницы уже существующей группы или проекта (меню Действия > Пригласить в группу ).
За все время своей работы с Битрикс мне довелось поработать с очень большим количеством проектов, которые кто-то разрабатывал до меня. Тут и мелкие доработки, фикс различных багов и ошибки работы логики, редизайн сайта и глобальные изменения существующего функционала. И, как и любой другой разработчик, я терпеть не могу разгребать чужой мусор, костыли и «временные» заплатки, которые на деле помнят еще 8 редакцию продукта.
Здесь я постараюсь не акцентировать внимание на стандартных «worst practice» при программировании на PHP, типа наплевательского отношения к выборам имен переменных и функций, излишних запросов к БД в цикле, отсутствия проверок пользовательских данных в формах, игнорирование комментариев и тому подобного. Я попытаюсь коснуться именно моментов, свойственных разработке на Битриксе, которые в последствии позволят избежать негодования и проклятий в ваш адрес от программиста, которому выпало сопровождать ваш код. И да, нередко этим программистом будете оказываться вы сами через год, или более, когда уже совершенно забудете, зачем вы вставляли сюда тот или иной костыль.
«Пишите код так, как будто сопровождать его будет склонный к насилию психопат, который знает, где вы живёте» (с) Джон Ф. ВудсПервое, и самое, на мой взгляд, важное - ради всего святого, используйте папку local . Это просто жизненно необходимо при использовании системы контроля версий – все, что вам нужно – добавить в исключения папку /bitrix/. Всё. Далее практически вся разработка ведется только в ней. Это заметно упрощает поиск нужных файлов и компонентов в последствии, помогает не засорять репозиторий лишними файлами, да и вообще – приводит дерево проекта в более опрятный, «человеческий» вид.
Не модифицируйте ядро . Даже если вы уверены, что оно не будет обновляться. Даже если так быстрее. Даже если вам лень. Забудьте эту мысль, как страшный сон. Если необходимо изменить логику работы стандартного компонента – перенесите его в новое пространство имен /local/components/modify/ и работайте с ним. То же самое касается модулей, гаджетов и activities бизнес-процессов.
Не засоряйте файл init.php . Объединяйте функции для работы с каким-то конкретным модулем или функционалом в класс, весь этот класс записывайте в отдельный файл, а в init.php просто подключайте эти файлы и прописывайте обработчики событий. Мне встречались файлы init.php по 500Kb, где в кашу были смешаны функции, определение констант, классы и инициализация обработчиков. Разумеется, когда приходилось разбираться в этих файлах, я сыпал проклятиями на своих предшественников.
Следующий пункт не касается случая разработки готовых решений для Marketplace, когда целью ставится сделать максимально настраиваемый функционал из публичной части для конечного потребителя. Если вы работаете над конкретным проектом, по конкретному ТЗ – не стоит пытаться сделать унифицированный шаблон для компонента на все случаи жизни . Лично я придерживаюсь философии – лучше несколько простых шаблонов, использующихся для разных целей, чем один универсальный, но в котором сам черт потом ногу сломит. Разумеется, в каждом конкретном случае нужно отталкиваться от того, что есть – техзадание, варианты реализации и тому подобное, но забывать про «Бритву Оккама» все-таки не стоит. Как пример приведу один проект лизинговой компании, который мне довелось править. Сам проект, конечно, был реализован ужасно, на настоящий ужас был в страницах раздела каталога услуг. У каждого из пяти разделов была собственная верстка, на которых отличалось как положение блоков на странице, так и в принципе наличие некоторых из них. И для всех пяти страниц использовался один шаблон с кучей if-else, дублированием вызовов компонентов, подключением стилей и скриптов, которые, к тому же, периодически конфликтовали друг с другом. Как итог – огромный файл, в котором разобраться «без поллитры» было смерти подобно. Хотя, казалось бы, что мешало сделать 5 разных шаблонов и не создавать трудностей на ровном месте?
Используйте API . Не изобретайте велосипеды там, где это не нужно. Юзайте документацию – весь продукт довольно хорошо описан, а так же каждую функцию можно посмотреть детально на bxapi.ru.
Избегайте прямых запросов к базе . Это частный случай предыдущего пункта – используйте API. Необдуманные, незащищенные запросы могут привести к порче, утере или даже к компрометации данных.
Не используйте компоненты с ЧПУ из корня сайта . Последствия, как правило, довольно печальны, так как ЧПУ использует файл обработчика адресов, попытка использовать его из корня легко ломает вам адресацию других компонентов, а так же 404 страницы. Ничего страшного не будет, если статьи у вас будут адресоваться относительно папки /articles/, а товары относительно /catalog/.
Подключайте css и js с помощью API. До сих пор повсеместно встречаю подключение скриптов и стилей с помощью html-тегов. Используйте объект класса \Bitrix\Main\Page\Asset и функции addJs() и addCss(). Это позволит объединять файлы и, в последствии, кешировать их одним нажатием чекбокса в настройках главного модуля
Ну и напоследок, ошибка касается не только Битрикса, но уж больно часто я стал встречать проблемы, связанные с ней. Проверяйте на пустоту массив с результатами выборки . Как пример, последний раз встретился с данной проблемой при работе с одним интернет-магазином. Жалоба: страницы иногда грузятся по 16 секунд. С чем связано – не ясно. Методом проб и ошибок выяснил, что страницы грузятся неприлично долго только тогда, когда корзина пустая. Казалось, с чего бы? Как выяснилось, у корзины при наведении появлялось всплывающее окно, в котором отображались изображения товара, положенного в корзину. Ну что сделал предыдущий разработчик? Взял результат работы компонента «маленькая корзина» и в файле result_modifier.php сделал вызов GetList() товаров для выборки изображений с фильтром из массива ID товаров, потом из результатов выборки в массив соответствующего товара добавлял src изображения. В итоге, когда товаров в корзине не было, фильтр уходил пустой, и в выборку попадал ВЕСЬ каталог товаров. Ну а дальше цикл по каждому и… имеем то, что имеем. Ясно, что на этапе разработки при тестовых 15 товарах это было незаметно, и проблемы возникли уже в боевых условиях. Хотя, казалось бы, чего стоило поставить проверку на empty($arResult[‘ITEMS’])…
На этом я заканчиваю свой личный топ «worst practice», касательно разработки на Битрикс. Если хоть кому-то данная информация поможет избежать ошибок в будущем и улучшить свой стиль разработки, значит это было не зря.
Вы можете помочь и перевести немного средств на развитие сайта
В этом сотрудничестве довольно много плюсов, основные из которых я расписал в этой статье.
Приток клиентов
1С-Битрикс большая и известная компания, десятки тысяч сайтов находятся под управлением cms Bitrix, а значит каждый день появляется множество заказов на создание сайтов, на перенос и, конечно же, на доработку функционала. Как правило, средний заказчик совсем не ориентируется в интернет сфере, и ему просто нужен сайт (ну или по крайней мере он так думает), и он не знает к кому обратиться. Довольно быстро, он выходит на сайт Битрикса (это слово, как минимум, на слуху) и пытается обратиться к ним, несмотря на то что на том же самом сайте написано, что эта компания не занимается разработкой сайтов, но эти заявки было решено собирать вместе и пересылать их своим партнёрам. А все мы знаем, что одна из самых больших проблем в бизнесе это как раз поиск клиентов, так что партнёрская программа здесь сильно помогает в поиске заказов.
Кстати, если вы живёте в Москве, вы можете, вообще, посадить своего сотрудника в офис Битрикса и он будет принимать телефонные заявки , таким образом вы будете получать ещё более подготовленных клиентов.
Поскольку одни из первых слов в вебе, которые узнаёт потенциальный заказчик, это "вёрстка", "битрикс", "домен", "seo", иметь в портфолио сайты под Битриксом очень большой плюс. Также будет большим плюсом к авторитету и любая другая связь с компанией 1С-Битрикс, к примеру: наличие сертификатов, статус партнёра, информация о вашей компании непосредственно на сайте Битрикса. И даже отсутствие проектов на других движках не будет минусом, часто даже при приёме на работу, то есть при общении с людьми, которые должны что-то понимать в этой сфере.
Marketplace
Как и у многих других крупных систем в IT-сфере, Битрикс имеет свой магазин решений с открытым доступом для сторонних разработчиков и возможностью монетизации своих продуктов, а это как никак пассивный доход от разработки. Отчасти из-за таких вещей программисты и считают, что сидят на золотой яме.
Но выкладывать платные решения могут только партнёры. Поскольку действительно много сайтов находятся под управлением этой cms, то и продажи в этом магазине идут очень активные. Так что на самом деле один только этот пункт может побудить вас оформить партнёрское соглашение, по крайней мере, так было со мной.
Скидки на лицензии
Самый большой минус cms Битрикс это цены. Она совсем не бесплатная, для примера, минимальная редакция для интернет-магазина на начало 2015 года стоит 27900р, но минимальная партнёрская скидка на неё - 11160р, что существенно. И так на каждую редакцию, мне кажется, что это ещё одна существенная причина подружиться.
Бесплатная лицензия (NFR-лицензия)
Есть ещё один способ партнёру сэкономить на лицензии. Есть пара способов получить для своих нужд абсолютно бесплатный экземпляр управления сайтом любой редакции . Данный сайт работает, например, на ней, на редакции "Эксперт". О способах получения NFR-лицензии я подробнее расскажу .
Битрикс24
Это веб-crm от 1C-Битрикс, бесплатная для партнёров. Честно говоря, я не оценил её по достоинству, так как я работаю в одиночку и мобильные аналоги полностью меня удовлетворяют, но мои же клиенты и просто знающие люди сильно расхваливали её. Для любой фирмы или команды фрилансеров, я думаю, это хорошее подспорье в бизнесе.
Ускоренная техническая поддержка Битрикса
Техподдержка - одна из визитных карточек 1с-Битрикса, если проблему не получается решить своими силами или с помощью документации или форумов, то можно обратиться в тех. поддержку и её обязательно решат. Но отвечает она вечность(сутки), но с помощью партнёрства это время можно сократить до нескольких часов.
Кратко подытожим
При партнёрстве с Битриксом вы получаете следующие плюсы:
- Авторитет в чужих глазах
- Скидки на лицензии
- Возможность заработка в Marketplace
- Бесплатную nfr-лицензию
- Свободный доступ к Битрикс24
- Ускоренную тех. поддержку
- Заявки на разработку
- И приглашения на огромное количество семинаров, конференций и вебинаров
Если вы заинтересовались, или просто хотите узнать, стоит ли игра свеч, прочитайте в данной главе, в которой рассказывается как раз о пути заключения партнёрского соглашения.