Комментарии

Главное в Битриксе это проблемы масштабирования

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

Тяжелая интеграция с современными средствами разработки публичной части сайта (верстки)

Современные решения: VueJS, Angular, React и т. п. позволяют ускорить и разработку сайта, и саму работу. Интеграция с 1С-Битрикс возможна, но она, наоборот, увеличивает время разработки.

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

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

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

И да, после меня в php_inerface останется ещё пара костылей, так принято, такие у нас традиции…

Докину ещё парочку «остроумных инженерных решений»:

1. Если в публичке в константе SITE_ID содержится id сайта, то в админке эта константа будет содержать id языка ( то есть «ru» вместо «s1» ).

2. (скорее всего, следствие из п.1) в админке не подключаются файлы раздельных init.php для сайтов ( то есть, например, /local/php_interface/s1/init.php )

3. некоторые методы в классах ядра объявлены как final, так что нельзя просто взять, отнаследоваться и переопределить; приходится подниматься выше по цепочке наследования и копипастить не совсем нужное.

Вот мои не «типичные аргументы о недостатках платформы»:

Инфоблоки без сомнения являются «сердцем» Битрикс, на них построено очень много решений, в частности каталог товаров в стандартных компонентах магазина. Чтож, попробуем создать инфоблок, заполяем замечательные поля NAME, CODE, IBLOCK_TYPE_ID и т.д.
А потом попробуем получить инфоблок — по названию (NAME) находит, по коду (CODE) находит, а по типу (IBLOCK_TYPE_ID ) — нет. Ну как так? А оказывается, для фильтра по типу нужно использовать ключ TYPE, а не IBLOCK_TYPE_ID. Почему, а главное, зачем?

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

Придумали D7, несколько лет назад, до сих пор создать элемент инфоблока нельзя. Зато у нас «ко-пилоты» и BI-аналитика в последнем обновлении.

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

Или вот, хочешь например сделать в инфоблоке свойство-привязку к разделу. Например что бы показывать сопуствующие товары для элемента, или комплектующие какие-нибудь — к этому же инфоблоку товаров привязать нельзя через админку. Ну почему? А потому что если ты вдруг это сделаешь, сломается непонятно что непонятно где, т.к. часть стандартных механизмов не умеет работать с отдельными свойствами-разделами, а сразу по всем смотрит. Ладно, делаешь отдельный инфоблок «сопутки» — так в некоторых компонентах нельзя 2 инфоблока выбрать\подключить.

Компанию по email получить нельзя… Email и телефоны в отдельную таблицу засунули, ладно многие-ко-многим, понятно. Но почему в эту же таблицу засунули и Email-ы контактов и лидов, всё в кучу.

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

Ух наболело, разошелся я что-то. Вот вам последняя загадка.

Как называется таблица в которой хранится URL сайта (для многосайтовости)?
Варианты:
1. b_site
2. b_url
3. b_domain
4. b_lang

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

А так: взяли битрикс, взяли шаблон «Аспро», вкатили изменения в дизайн настройками Аспро, воткнули одно в другое, отдали — и пусть изучают в реальности, что им на самом деле от интернет-магазина надо.

А «программист» тут нужен для маркетинга.

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

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

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

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

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

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

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

Не люблю Битрикс и не в коем случае не хочу проводить тут активно рекламу, приведу лишь кейс из практики

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

Провели технический аудит и обнаружили:
— Низкое качество программной реализации.
— Несоблюдение стандартов разработки на 1С-Битрикс и отсутствие документации.
— Множество источников скрытых ошибок.
— Уязвимости для безопасности сайта.
— Места с повышенной нагрузкой.
— Легаси от нескольких подрядчиков с различными стилями написания кода и отсутствием единой концепции.

Устранив большинство проблем и проведя рефакторинг, мы полностью решили вопросы со скоростью работы сайта.

Как проходит аудит и что получает заказчик

Что входит в техаудит:
— Анализ работы сервера, кода и программной архитектуры.
— Стандартные тесты 1С-Битрикс: качества, производительности, безопасности, работы модулей и компонентов.
— Frontend-тестирование: кроссбраузерное и кроссплатформенное тестирование верстки на реальных устройствах, а также с использованием сервисов.
— Нагрузочное тестирование: выявление предельных нагрузок, анализ достаточности настроек ПО сервера, анализ результатов и рекомендации.
— Функциональное тестирование: корзины, оформления заказа, личного кабинета, регистрации и других элементов функционала.

Что в результате

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

Так что да проблемы у Битрикса есть, но в большинстве случае их можно решать, хотя и сложно

Так ли плох Битрикс на самом деле? Разбираем возможные причины технических проблем и низкой скорости интернет-магазина

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

Если сайт работает с ошибками и сбоями, то встает вопрос «Кто виноват?»

Нередко исполнители грешат на Битрикс. Типичные аргументы о недостатках платформы:
— Проблемы при интеграции с 1С.
— Недостаточная гибкость архитектуры.
— Проблемы при обработке данных из нескольких источников.
— Разрастание объема хранимых данных.
— Проблемы масштабирования.
— Сложная интеграция с современными средствами разработки верстки.

Но так ли плох Битрикс на самом деле? Кейс из практики

Клиент готовился к запуску нового сайта на готовом решении Aspro для Битрикс вместо старого — на Python. Но при перенаправлении на новый ресурс всего лишь 30% трафика (20 тысяч пользователей в сутки) он переставал выдерживать нагрузки и падал.

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

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

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

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

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

Сбои в работе интернет-магазина — это прямое влияние на бизнес. Чем больше проблем, тем больше барьеров на пути пользователя, ниже конверсия и больше потерь.

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

Такс, напомните пожалуйста, в Битриксе до сих пор пишут страницы на php? Шаблонизатор так и не завезли? Ну типа там Twig.

Кейс из нашей практики работе с 1с-Битрикс

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

Провели технический аудит и выяснили:
— Структура кода требовала оптимизации.
— Имелись функциональные проблемы и ошибки в верстке.
— Некоторые модули 1С-Битрикс были настроены и использовались некорректно.

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

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

1. Ошибки при работе непосредственно с платформой Битрикс. Самая распространенная проблема — ошибки в работе типового функционала из-за модификаций в ядре 1С-Битрикс.

Есть еще одна серьезная проблема — создание самописных компонентов без особой необходимости вместо использования сложных комплексных и стандартных от Битрикс. Это вызывает проблемы при попытках расширения функционала, обновлении CMS и при развитии проекта.

2. Ошибки backend-разработки на PHP и Bitrix API. Запросы к БД в цикле, лишние файлы, служебные скрипты в открытом доступе, отсутствие защиты при обращении к GET- и POST-параметрам.

3. SQL-запросы в файлах страниц, шаблонах, запросы в циклах. Ошибки логики, постоянные повторы ошибок и, как следствие, высокая нагрузка на сайт и замедление его работы.

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

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

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

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

8. Низкий уровень безопасности сайта. Уязвимости к SQL-injection и Cross-Site Scripting. Файлы сессий, которые позволяют мошенникам получать доступ ко всем проектам на хостинге. Отладочная информация выводится на страницах публичной части, служебные файлы доступны по URL.

9. Не настроен сервер и его окружение. При повышении посещаемости сайт замедляется или вовсе отказывается работать. В итоге ресурс теряет позиции в поисковых системах и возможных клиентов.

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

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

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

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

Так если есть возможности что лучше тогда выбрать — Headless CMS, для высоконагруженного проекта?

Headless CMS — это серверная система управления контентом, которая работает в основном как хранилище. Она делает контент доступным через API для отображения на любом устройстве без встроенного интерфейса или презентационного слоя.

Некоторые преимущества Headless CMS:

— Разнообразие каналов контента. CMS можно подключить к любому количеству фронтендов и выводить контент на любые устройства, сайты и мобильные приложения.
— Согласованность работы. Не нужны несколько отдельных команд для каждого наполнения, можно максимально оптимизировать ресурсы и сэкономить на работе специалистов.
— Конфиденциальность. Риск утечки данных минимальный, так как c контентом работают без привязки к интерфейсу.
— Высокая скорость загрузки. За счёт того, что передача происходит через API, статичный контент будет отображаться моментально как на крупном сервисе, так и на одностраничном лендинге.
— Экономия ресурсов. Благодаря подключению к CDN не требуется проводить нагрузочное тестирование и привлекать специалистов для настройки балансировки серверов.

Выбор между Headless CMS и традиционной CMS зависит от требований проекта и его технических возможностей.

Объясните как понять что безголовая CMS работает как хранилище и в чем ее все таки осные преимущества, только простым языком, чтоб было понятно.

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

Логика Директа, когда заголовок объявления = запросу пользователя, в нашем случае не работает. Точнее, не показывает сколько-нибудь значительного роста конверсии или даже ее снижает.
Мы называем это «большое релевантное пятно», когда есть задача выделиться из некого списка (поисковой выдачи). Но при переходе на сайт (посадочную страницу) необходимо попасть в потребность пользователя. Не «столик заказать Санкт-Петербург», а «Забронировать столик в лучшем ресторане Санкт-Петербурга за 5 минут без депозита». Чувствуете разницу?

Следующая ситуация – не настроены цели и нет А/В тестов. Это значит, что у вас нет статистики по целям, следовательно, невозможно понять эффективность подмен. Чаще всего при объемной настройке динамического контента пользователи нашей системы промахивались. Для получения результата нужно несколько итераций (этапов), а без А/В тестов это невозможно. Как выявлять элементы, которые сработали хуже?

И еще – подмена второстепенных элементов, которые не влияют на конверсию (например, подпись на кнопке с «Заказать обратный звонок» на «Перезвоните мне». Это бесполезный труд.

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

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