Что нужно знать о Битриксе некоторым потенциальным покупателям

    Эта статья написана не для холивара. Здесь не будет полного обзора плюсов и минусов. Это просто несколько фактов из моего опыта, которые я сам хотел бы знать, перед тем как выбрать 1С Битрикс в качестве CMS.

    Предыстория, которую можно не читать


    Давным-давно, когда словосочетание «web 2.0» было модным, а тени с округлостями были верхом дизайнерской мысли, нашей организации понадобилось упорядочить общение с клиентами и завести себе HelpDesk. И как это обычно бывает, работы по выбору, установке, настройке и внедрению были поручены автору затеи, то есть мне – рядовому сотруднику техподдержки.

    image

    Навыки программирования у меня на тот момент были исчезающее малы – немного ковыряния в вордпрессе и пара бесполезных «Hello World!» написанных в Notepad++. И вот с этим багажом знаний я свободное от звонков время стал читать мануалы к имеющимся на рынке на тот момент системам HelpDesk и ServiceDesk.

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

    Так вот к чему это я. Мы выбрали редакцию 1С Битрикс – Управление сайтом (БУС на местном сленге) не для интернет магазина. И модуль интернет магазина никогда не использовали (почти). Этот факт сильно сказался на «пользовательском опыте», каким образом – опишу ниже.

    Факт 1. Битрикс: Управление сайтом ≈ Интернет магазин


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

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

    image

    Где-то внутри появилось «ядро D7», но документация об этом не знает (а в коде там не всё очевидно, иногда до нужного места можно добраться только перелопатив 5-7 файлов).

    Из чего-то действительно полезного можно вспомнить парноидальный кэш, названый «Композитный сайт». Но все кто видел как битрикс строит запросы, и без композитного кэша понимали что лишний раз базу лучше не беспокоить.

    Те модули, которые не нужны интернет магазину, существуют для галочки в списке фич на промо страницах битрикса. Они более менее работают, но не развиваются. Модуль техподдержки каким был в середине нулевых, таким и остался к 2015 году. Форум, wiki, блоги, обучение – это всё мало изменилось со дня своего появления.

    Вывод: если вам не нужен интернет магазин и вы планируете использовать другие модули, то не рассчитывайте на их развитие.

    Факт 2. Долгое исправление ошибок


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

    Сейчас, например, в админке модуля техподдержки нельзя осуществить поиск обращений по email’у среди обращений поступивших по почте. Некритично, но неприятно. Висит этот баг уже с прошлого года =)

    Вывод: если нашли ошибку в модуле – не рассчитывайте на быстрое её устранение (но сообщить о ней стоит)

    Факт 3. Медленные инфоблоки


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

    Информационные блоки — ключевой момент Bitrix Framework. Практически всё, что делается в системе в той или иной мере завязано на этот модуль, даже если это и не отображается явно.

    dev.1c-bitrix.ru/learning/course/?COURSE_ID=43&CHAPTER_ID=04610&LESSON_PATH=3913.4610

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

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

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

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

    Этот подход не доставляет проблем при небольшом количестве записей (зависит от настроек и производительности сервера базы данных) Но когда записей становится несколько миллионов, появляются запросы исполняющиеся за неприличное время. И чем дальше, тем более неприличным это время становится.

    image

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

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

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

    Факт последний. НЕНАВИСТЬ!


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

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

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

    image

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

    Общий вывод


    Если вы не планируете пользоваться модулем интернет магазина, но планируете создать популярный динамичный сайт, то битрикс с этим справится. При этом нужно учитывать, что количество накладных расходов может быть больше чем при выборе другой системы. Лучше внимательно взвесить все за и против.
    Метки:
    Поделиться публикацией
    Комментарии 67
    • –13
      Битрикс — это не только интернет магазин. Есть ещё Битрикс24, который активно развивается. Чертей своих у него тоже хватает, но потребители жрут его даже за бугром, ведь он такой няшный…
      • +3
        Битрикс24 это отдельная история. Пользователей БУС она не затрагивает =)
        • +4
          Б24 и семейство битрикс цмс это совсем разные продукты, нельзя их сравнивать.
          • +3
            Чем разные?
            Вы внутре Б24 ковыряли (коробочную версию, а не облачную)? Обычный битрикс с кастомным решением и модулями.
            • 0
              Морская свинка какая-то — ни к морю, ни к свиньям отношения не имеет.
          • 0
            Ну, не знаю на счет репутации «у работников веб-студий». Как только ценник за сайт переваливает за стоимость пиццы на неделю, так сразу овербольшинство студий оказываются партнерами этого самого битрикса.
            Добавлю также, что с интернет-магазином тоже не все айс. С подписками, с аффилиатной программой и т.д. — для галочки есть, по факту долго курим код на предмет «почему не работает». Но конкретно для сайта типа каталог товаров и/или интернет-магазин все отлажено, документировано, интегрировано и по факту — ничего более лучше адаптированного к нашим просторам нет.
            • –12
              Я уважаю Битрикс, это большой добротный проект с отличной функциональностью и если он подходит под нужды бизнеса, то стоит выбирать не задумываясь.

              Но вот двухсмысленные намёки на репутацию весьма неприятны, она точно заслуженная
              www.govnokod.ru/search?search=bitrix&language=
              www.govnokod.ru/search?search=%D0%B1%D0%B8%D1%82%D1%80%D0%B8%D0%BA%D1%81&language=
              Думаю, треть претензий там надуманные и уже исправлены, но представление уже можно составить.
              • +2
                Лично меня там убивает создание страниц в файловом варианте через index.php (— а почему я должен создавать именно index.php в этой папке, товарищ программист? ) и визуальник, который тянется с 2007 года.
                • +3
                  А какой файлик вы хотите создавать в папке? Вы можете создать любой(хоть mega-page.php), это же просто файловая структура. А index.php это просто настроены веб-сервера на обработку именно index.php по-умолчанию.
                  Я для себя решил и всем рекомендую так делать — работать только с разделами(папки с index.php внутри). Непонятностей и проблем меньше(с теми же хлебными крошками).

                  У каждой CMS свои особенности, которые надо учитывать.

                  И визуальный редактор за последние пару лет уже раза два переделали.
                  • +3
                    Так в том то и дело что это не «просто». Вы предлагаете изначально логичный вариант, который решает технические проблемы и который должен быть по умолчанию, раз вы его повторяете регулярно. Эволюция систем в том и состоит, чтобы выбирать лучшие решение в разных ситуациях.
                    Битрикс забил на контент менеджеров практически сразу со своего создания. Ибо они в прекрасной коммерческой модели битрикса вообще никто. Они не внедряют, не покупают, не продают, не обучают. Они самые конечные пользователи и не имеют права возмущаться ибо им тупо дают логин и пароль. Максимум ссылку на обучалку.

                    Я не хочу вообще создавать файлов, которые нужно помещать в папки. Это обязывает объяснять пользователям файловую структуру сервера (причем линукса, да, есть и другие операционные системы, а операционная система это вот среда где...), что такое папки и типы файлов, запускаемые по умолчанию при обращении сервера к директории. В некоторой степени это вообще просто смех. Какое отношение это имеет к выполнению задачи, «написать про Васю вот чтобы тут открывалось». У людей мозг взрывается от объяснений.

                    Многие очевидные вещи для программиста битрикс обязывает обучать секретаршу тулгорводоканала. У них округляются глаза, а почему «Index.php»? А по русски писать нельзя?
                    Отдельный разговор о «вставка из ворда». Многие пишут изначально в нем, потом шеф утверждает и это переносится на сайт. Я не хочу объяснять почему с ворда тянется куча тегов, я не хочу объяснять что такое теги вообще. CKeditor это делает по умолчанию, все что не в html5 вырезается. Он в своей третьей версии тоже имел кнопку «вставка из ворда». А в 4-ой я ее искал искал пока меня не озарила гениальность сего решения:-)

                    Типичные задачи пользователя в битриксе не сделаны просто в рамках особенностей cms. Так как особенность подразумевает какое то поведение и движение в своих уникальных рамках. А их тут нет. Визуальник как я видел в 2007 так он такой и остался. :-)
                    • 0
                      Сначала вы пишете про " создание страниц в файловом варианте", а потом «Я не хочу вообще создавать файлов, которые нужно помещать в папки.». Вы уж решитесь в каком режиме вы работаете в админке :) Там даже где то в настройках есть галочка типа «убрать пункт Файл и папки» и ни вы, ни секретарша из Тулгорводоканала никогда не столкнетесь с index.php

                      «Битрикс забил на контент менеджеров практически сразу со своего создания. „
                      Не согласен. Как раз для контент-менеджеров сделано много, я б даже сказал, что местами слишком(кастомные стили для виз.редактора, визуальное редактирование настроек компонентов и т.п.).

                      Виз.редактор они в новой версии, говорят, сильно допилили. Про вставку из Ворда тоже говорили.

                      А насчет автоматической очистки от лишних тегов — ох сложная тема. Вот так настроишь очистку, а потом претензии — “я вот 3 часа игралась со шрифтами и цветами, а они на странице выглядят по другому». Лучше сразу объяснять как правильно делать.

                      «Визуальник как я видел в 2007 так он такой и остался. :-)»
                      Попробуйте обновить вашу редакцию Битрикса :) все таки даже Битрикс за 8 лет существенно изменился, хотя бы внешне )
                      • –1
                        Битрикс хранит содержание страниц в файлах с возможностью перемешки php — отсюда и все вытекающие минусы.
                        Объяснения файловой системы, правильных имен файлов, кириллицы от латиницы, что к созданию страниц, как сущности, не имеет отношения.

                        Вы описываете визуальник битрикса как будто он такой один :-). CKEDITOR по удобности настройки и работы для меня вне конкуренции с битриксовым. Посмотрим что они там допилили. Вау, последний апдейт — наконец то обновили визуальник, прям не верю. С 2007 года он менялся до последнего релиза.

                        Автоматическая очистка тегов обязательна, поскольку <font attr=«MSO-Tahoma или какой то то там ужас все равно браузером не воспроизводится а в коде он находится. Лучше конечно сразу объяснить, как делать. Тока лучше чем парсер этого не объяснить :-)
                      • +2
                        Еще раз посмотрел админку Битрикса… Действительно там все таки участвует понятие папки, а не раздела. Просто привык работать из публичной части сайта.

                        Ну буду спорить. Многим не нравится интерфейс админки Битрикса. Да в нем есть свои заморочки. Но по совокупности, мне кажется все таки юзабилити получше будет, чем у многих. Работал и с Вордпрессом, и Джумлой и Друпалом немного.
                  • +1
                    Если вы посмотрите как написаны шаблоны битрикса, (яркие представители это шаблоны магазина, каталог например), то там сам чёрт ногу сломит. Я по себе знаю все это, делал не только магазины, но и типовое решение для маркетплейс.

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

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

                    И это далеко не все, но конечно есть и плюсы, но их видят в основном только те кто продаёт систему или кто просто не видел ничего лучше этой системы.
                  • +2
                    Много лет наблюдаю за этим проектом. Впечатление, в общем, не изменяется: ребятам дают бюджеты «на разработку», они их добросовестно «осваивают».

                    Командует тот, кто дает бюджеты. Те, кто осваивают — с большим энтузиазмом отчитываются. За освоение.

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

                    О чем это может говорить?
                    • –1
                      Нужно просто иметь мозг и не слушать маркетологов, хотя это наверно в другой галактике. А по факту, бюджеты большие, рабы на фрилансе дорогие, откаты не маленькие. В целом все печально.
                      • 0
                        С битриксом есть ещё такая проблема, что часто им занимаются студенты, которые пришли в какую-нибудь веб-студию поработать на практику.
                        Есть и более опытные разработчики под Битрикс, которые либо не понимают, куда можно расти дальше, либо работают по принципу «нас и здесь неплохо кормят».
                        И если попасть ко вторым с заказом — это ещё более-менее нормально, то первые будут радовать результатами раз за разом.
                        • +1
                          Опыт важен в любой работе. Новички косячат везде.

                          «которые либо не понимают, куда можно расти дальше»
                          а куда расти опытному программисту на Битриксе вы посоветуете? Больше языков хороших и разных? Есть мнение, что неплохо бы знать о многих технологиях(за всем не успеешь), но быть экспертом в какой то узкой нише.
                          • +1
                            Не с моим опытом советы раздавать, выше описанное — это наблюдения со стороны нескольких лет работы, в том числе и в веб-студии. Но для себя решил, что Битрикс — тупик. Там довольно старая кодовая база, чему-то новому там быстро становится сложно учиться. Сам сейчас работаю с Symfony. Хоть фреймворк и очень нравится, но в перспективе хочу смотреть на другие языки, так как PHP пока что не очень приспособлен к решению некоторых задач (есть всякие ReactPHP, но это немного не то).
                            Опыт важен в любой работе. Новички косячат везде.

                            Тут вопрос к бизнесу: насколько он хочет, чтобы именно на его сервисах новички получали опыт.
                            Есть мнение, что неплохо бы знать о многих технологиях(за всем не успеешь), но быть экспертом в какой то узкой нише.

                            Ну, это что-то близкое к тому, что я имел в виду под «нас и здесь неплохо кормят». Можно обосноваться в популярной нише и заниматься более-менее похожими вещами, получая стабильный доход.
                            Я не вижу ничего страшного в этом. Это скорее всего рано или поздно в любом случае произойдёт. Только не у всех с Битриксом и не у всех с PHP.
                            Чтобы не было недопонимания, уточню: я PHP люблю, а не ненавижу как многие, но и недостатки его понимаю.
                            • 0
                              Правильно, выберите нишу, решите для себя чем хотите заниматься. Битрикс это однозначно тупик. Сейчас я выбрал для себя nodejs angular mobgodb, ну и go в перспективе и чем больше углубляюсь в этом направлении, тем больше жалею о потраченных годах с битрикс.
                          • 0
                            В целом со статьей согласен. Но не согласен, что система слабо развивается. Не все внешне можно увидеть. Очень много возможностей появляется по оптимальной настройке и масштабированию проектов на Битриксе. Очень неплохо за эти пару лет развили свою BitrixVM.
                            В этом году у Битрикса упор на конверсию, маркетинговые фишки для сайтов. Много улучшений для контент-менеджеров в визуальном редакторе, в обработке картинок для сайта.

                            Меня, в свою очередь, раздражает, что очевидные ошибки и полезные, нужные предложения(idea.1c-bitrix.ru) очень долго внедряются.
                            Более 3000 предложений(и ошибок), которые Битрикс сам согласился рассмотреть, и только 200 в работе.
                            • +1
                              Похоже, что вы в курсе экосистемы, поэтому спрошу вас, так как самому интересно.
                              Я когда ещё наблюдал за работой с Битриксом где-то в 2013 году слушал вебинары про разработку на нём и спрашивал у ведущих, как делать в Битриксе миграции. Мне отвечали, что делать их можно инфоблоками или отдельными standalone-скриптами.
                              Что-то в этом плане поменялось?
                              • +1
                                Мне кажется миграции базы данных вообще сложная тема в любой системе ) Обычно разработчик вручную их создает.

                                По сути так все и осталось — или экспорт-импорт инфоблоков(xml) или свои скрипты с использованием API Битрикса, ну или ручная синхронизация :)
                                По крайней мере я больше вариантов не видел.
                                • +1
                                  Ясно, спасибо. Жаль, что ничего не изменилось.
                          • 0
                            Инфоблоки — сущность, которая в физической структуре БД создает 4 таблицы, не меняющиеся при изменении структуры данных: типы объектов, экземпляры объектов, свойства объектов и значения свойств объектов.

                            В настройках каждого инфоблока есть волшебный пункт — «где хранить данные: в общей таблице или отдельной». собственно эта настройка появилась там уже как 3-5 лет (точно не помню), но ваш этот минус нивелирует полностью… Хотя бы из одного этого видно как вы читаете документацию и тем более, как качественно, вы освоили курсы Битрикса… А они весьма подробные и исчерпывающие…
                            • +3
                              Я же написал — минус в том, что свойства хранятся отдельно от объектов которым принадлежат. А тот пункт, о котором вы говорите как раз так и называется
                              Значения свойств хранятся: в отдельной таблице для данного информационного блока


                              Это значит что для каждого типа свойства каждого инфоблока в БД появится отдельная таблица:
                              Значения свойств хранятся в 2-х таблицах (описание таблиц и их структуры имеет справочный характер и могут меняться в следующих версиях):
                              b_iblock_element_prop_mNN — для множественных. Имеет ту же самую структуру, что и b_iblock_element_property;
                              b_iblock_element_prop_sNN — для единичных. Имеет поле IBLOCK_ELEMENT_ID — ID элемента инфоблока которому принадлежат свойства:
                              PROPERTY_XX — хранит значения единичного свойства XX или кэш значений для множественного свойства;
                              DESCRIPTION_XX — хранит описание для единичного свойства.


                              Вот такие таблицы для инфоблоков на создались нашем проекте:

                              b_iblock
                              b_iblock_cache
                              b_iblock_element
                              b_iblock_element_iprop
                              b_iblock_element_lock
                              b_iblock_element_prop_m100
                              b_iblock_element_prop_m101
                              b_iblock_element_prop_m102
                              b_iblock_element_prop_m103
                              b_iblock_element_prop_m104
                              b_iblock_element_prop_m33
                              b_iblock_element_prop_m34
                              b_iblock_element_prop_m35
                              b_iblock_element_prop_m44
                              b_iblock_element_prop_m45
                              b_iblock_element_prop_m46
                              b_iblock_element_prop_m47
                              b_iblock_element_prop_m49
                              b_iblock_element_prop_m50
                              b_iblock_element_prop_m51
                              b_iblock_element_prop_m52
                              b_iblock_element_prop_m53
                              b_iblock_element_prop_m54
                              b_iblock_element_prop_m56
                              b_iblock_element_prop_m59
                              b_iblock_element_prop_m61
                              b_iblock_element_prop_m62
                              b_iblock_element_prop_m63
                              b_iblock_element_prop_m65
                              b_iblock_element_prop_m72
                              b_iblock_element_prop_m73
                              b_iblock_element_prop_m74
                              b_iblock_element_prop_m75
                              b_iblock_element_prop_m76
                              b_iblock_element_prop_m77
                              b_iblock_element_prop_m78
                              b_iblock_element_prop_m79
                              b_iblock_element_prop_s100
                              b_iblock_element_prop_s101
                              b_iblock_element_prop_s102
                              b_iblock_element_prop_s103
                              b_iblock_element_prop_s104
                              b_iblock_element_prop_s33
                              b_iblock_element_prop_s34
                              b_iblock_element_prop_s35
                              b_iblock_element_prop_s44
                              b_iblock_element_prop_s45
                              b_iblock_element_prop_s46
                              b_iblock_element_prop_s47
                              b_iblock_element_prop_s49
                              b_iblock_element_prop_s50
                              b_iblock_element_prop_s51
                              b_iblock_element_prop_s52
                              b_iblock_element_prop_s53
                              b_iblock_element_prop_s54
                              b_iblock_element_prop_s56
                              b_iblock_element_prop_s59
                              b_iblock_element_prop_s61
                              b_iblock_element_prop_s62
                              b_iblock_element_prop_s63
                              b_iblock_element_prop_s65
                              b_iblock_element_prop_s72
                              b_iblock_element_prop_s73
                              b_iblock_element_prop_s74
                              b_iblock_element_prop_s75
                              b_iblock_element_prop_s76
                              b_iblock_element_prop_s77
                              b_iblock_element_prop_s78
                              b_iblock_element_prop_s79
                              b_iblock_element_property
                              b_iblock_element_right
                              b_iblock_fields
                              b_iblock_group
                              b_iblock_iblock_iprop
                              b_iblock_iproperty
                              b_iblock_messages
                              b_iblock_offers_tmp
                              b_iblock_property
                              b_iblock_property_enum
                              b_iblock_right
                              b_iblock_rss
                              b_iblock_section
                              b_iblock_section_element
                              b_iblock_section_iprop
                              b_iblock_section_property
                              b_iblock_section_right
                              b_iblock_sequence
                              b_iblock_site
                              b_iblock_type
                              b_iblock_type_lang
                              b_seo_sitemap_iblock
                              b_utm_iblock_103
                              b_utm_iblock_12
                              b_utm_iblock_25_section
                              b_utm_iblock_40_section
                              b_utm_iblock_60
                              b_utm_iblock_78
                              b_utm_iblock_80
                              b_uts_iblock_103
                              b_uts_iblock_12
                              b_uts_iblock_25_section
                              b_uts_iblock_40_section
                              b_uts_iblock_60
                              b_uts_iblock_78
                              b_uts_iblock_80


                              Печалька начинается когда нужно получить данные из нескольких связанных инфоблоков. При большом объеме данных это очень небыстро.
                              • +1
                                Ну значит это проблема не инфоблока, а неверной реализации задачи…
                                В любой CMS есть возможность писать свои модули… и Битрикс не исключение…
                                Изначально инфоблоки это представление данных, для новостей и магазина… Собственно с этим то онии как раз замечательно и справляются… Для остального можно написать свой модуль со своей таблицей, которая будет сделана идеально под конкретную задач…
                                Нельзя и рыбку съесть, и на… й сесть) В плане удобства и универсальности одновременно, всегда надо чем то жертвовать((
                                • +1
                                  Весь наш код вынесен в модули. Без этого не получится нормально кешировать всё что нужно и будет плодиться постоянный копипаст. по-моему, так делают все.

                                  А по по поводу таблиц. Главный плюс инфоблоков — разруливание прав и интерфейс админки. Если от всего этого отказаться, то зачем тогда битрикс?
                                  • –3
                                    У битрикса есть подробнейшая инструкция по созданию собственных модулей (и компонентов) собственно там же есть инструкция по организации разграничения прав…
                                    Кеширование делается вообще в один присест… И все нормально делается… надо вам кешировать html пожалуйста, надо только данные, так же просто… Нужно чтобы кеш зависел от каких то эфемерных параметров (дата, ID пользователя, фаза луны) тоже элементарно.
                                    То, что вы будете делать свой модуль с блекджеком, и всем причитающимся, не отменяет всех фишек битрикса… )
                                    И даже больше свой собственный модуль позволит сделать более удобное меню в админке, сделать свою страницу настроек, если это необходимо…
                                    Ну и главное, что для этого есть документация… да она не всегда актуальна, но она есть и не надо искать на каких то непонятных сайтов любителей инструкцию…

                                    Ну и + если вы сделаете какой-то реально охрененный модуль, вы можете его продать еще раз через маркетплейс…
                                  • 0
                                    >Изначально инфоблоки это представление данных, для новостей и магазина… Собственно с этим то онии как раз замечательно и справляются…

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

                                    Забивать ид ручками в новости не предлагать.
                                    • +1
                                      Самый просто вариант — сделайте 4 инфоблока и подключайте нужный в зависимости от языка. А используя ЧПУ адрес будет всегда одинаковый… никаких ID
                                      Есть такое поле как CODE его можно использовать как адрес.
                                      • –1
                                        Как определить, какой нужный? В этом-то и был вопрос.

                                        Как может быть одинаковый адресс у разных новостей?

                                        + учитывайте древовидность, связи раздел-подраздел-новость
                                        ссылку по верхним связям тоже должны быть интернационализованы,
                                        что бы нажимая на «news» пользователь не попадал в «новости»
                                        • 0
                                          Адрес страницы может автоматически генерироваться из например заголовка…
                                          Тоетсь новости могут иметь один и тот же url, а на основании него и языковой константы будет подбираться инфоблок… не вижу проблемы в том чтобы новости дать 1 и тот же адрес…

                                          То есть новость с заголовком «Новость» будет иметь поле CODE = news
                                          C заголовком «News» — тоже news
                                          И так далее…

                                          Это поле может генерироваться битриксом автоматически и если ваш редактор не будет придумывать РАЗНЫЕ заголовки для новостей на разных языках… то и адреса будут одинаковые…

                                          А учитывание древовидности — #SITE_DIR#/folder/#SECTION_CODE_PATH#/#CODE#/

                                          p.s. не утруждайся ответом. у тебя видно же цель — доебаться и показать что битрикс говно… и на нем даже такую простую задачу не реализовать, лучше использовать «вписать название фреймворка, CMS»…
                                          • +2
                                            Я вроде вам не тыкал, но это ничего, да. Сейчас модно-молодёжно так.
                                            Продолжайте в стиле #php (=

                                            Ничего, что slug-ги вообще-то тоже хорошо бы интернациолизировать?
                                            Что бы не было смешных казусов когда слово-фраза смешно звучит в другом языке?

                                            >Тоетсь новости могут иметь один и тот же url, а на основании него и языковой константы будет подбираться инфоблок…

                                            Как вы будете хранить привязку инфоблок — язык?
                                            В четырёх вариантах?

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

                                            Еще, тех же времён проблема — получить список стран.
                                            GetCountryArray в забавном виде отдавала список, а GetCountryByID толи небыло толи не работало.

                                            >p.s. не утруждайся ответом. у тебя видно же цель — доебаться и показать что битрикс говно… и на нем даже такую простую задачу не реализовать, лучше использовать «вписать название фреймворка, CMS»…

                                            Нет, что Вы! Моя цель показать, что битрикс всегда был на грани прогрессивных решений и внедрений новых концепций! Это был самый совершенный продукт с которым я столкнулся.
                                            Одно количество файлов, сгенерированных белковыми искусственными(?) интеллектами чего стоит.

                                            Слава роботам!
                                            • 0
                                              Ну о чем я и говорил…
                                              Можно было не тратить байты, позиция была изначально ясна…

                                              p.s. дичайше извиняюсь за «ты», свет от Вашей короны меня слегка ослепил и меня бес попутал… )
                                          • 0
                                            Адрес страницы может автоматически генерироваться из например заголовка…
                                            Тоетсь новости могут иметь один и тот же url, а на основании него и языковой константы будет подбираться инфоблок… не вижу проблемы в том чтобы новости дать 1 и тот же адрес…

                                            То есть новость с заголовком «Новость» будет иметь поле CODE = news
                                            C заголовком «News» — тоже news
                                            И так далее…

                                            Это поле может генерироваться битриксом автоматически и если ваш редактор не будет придумывать РАЗНЫЕ заголовки для новостей на разных языках… то и адреса будут одинаковые…

                                            А учитывание древовидности — #SITE_DIR#/folder/#SECTION_CODE_PATH#/#CODE#/

                                            p.s. не утруждайся ответом. у тебя видно же цель — доебаться и показать что битрикс говно… и на нем даже такую простую задачу не реализовать, лучше использовать «вписать название фреймворка, CMS»…
                                • +4
                                  Косяков на самом деле гораздо больше, чем раскрыто в статье. Но и достоинств тоже есть. Для себя формулирую отношение к этой CMS как «приятно делать из говна конфетку». Эта формулировка остужает и расставляет всё на свои места.

                                  У меня за плечами опыт разработки буквально любого ПО на тьме языков, архитектур и инструментов. И я могу сказать, что посты ненависти легко можно написать про всё. Буквально вообще про всё. А вот научиться выбирать и, главное, потом использовать инструмент правильно — гораздо, несравненно более сложно.

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

                                  Хватит жаловаться. Просто делайте свою работу, это далеко не самая ужасная работа на свете. ;)
                                  • +1
                                    «приятно делать из говна конфетку».
                                    Полностью согласен, но когда делаешь конфетку из шоколада, а не из похожей только по цвету консистенции, это гораздо приятнее.
                                  • +8
                                    Не холивара ради, но для полноты картинки, вставлю свои пять копеек как сисадмин Linux.

                                    1. Для нормальной работы Битрикса требуется действительно быстрая машина, а если посетителей на сайте будет больше одного, то еще и на ssd. Одна из самых тяжелых CMS ( если не самая тяжелая ), в стандартной поставке — установил и работай производительность просто никакая.

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

                                    з. Вот вам деньги, оптимизируйте сервер под битрикс
                                    а. Готово, все кешируется нужное время, админ панель не кешируется, настройки сервера оптимальные
                                    з. Ничего не готово. Я купил сервер за 200$ в месяц, в панели производительности стоит 50 вместо эталона 30, я хочу 120. У моего друга все быстрее, он платит всего 100$ а попугаев 56. Работа не выполнена, никаких денег, держите злобный отзыв.
                                    а. Битрикс работает быстро? Страницы открываются быстро?
                                    з. Да быстро, но не доволен производительностью, до свидания.
                                    • 0
                                      Назад-то все вернули?
                                      • +1
                                        Естественно, если заказчик полностью отказывается от оплаты, сразу же откатываю настройки к стандартным ( опыт научил делать бекап конфигов до начала изменений ), сообщаю об этом и удаляю публичный ключ с сервера.
                                      • +1
                                        Как такой же сисдамин подпишусь.
                                        У битрикса очень многое упирается в базу. Если она нормально настроена и вся влезает в память (innodb), то сайт достаточно шустрый и без всяких SSD. Бывают, конечно, случаи говнокода при разработке, которые тормозят весь движок, но это отдельная песня.
                                        Конечно, попугаи производительности так ещё ш(ут|ту)ка. Как и провещик конфигурации. Например, эта скотина отправляет почту, где в качестве домена отправителя использует hostname машины, с чем частенько категорически не согласен opensmtpd (кривой отправитель). А так же весёлые настройки размера стека и прочие шалости.
                                        Отдельно доставлял (не знаю, как сейчас, сталкивался с этим моментом 3 года назад) скрипт-автооптимизатор в автозагрузке их официального центосёвого образа, который вычисляет «оптимальные» параметры (основываясь на размере памяти машины) для MySQL и выставляет их при каждой загрузке. И срать он хотел, что ты там наоптимизировал, если забыл выключить этот скрипт.
                                        • 0
                                          Если Вы работали с битриксом больше одного раза, то знаете великолепную формулу, по которой высчитываются попугаи ( 1 / Среднее время отклика ). В этой формуле не учитывается скорость работы с базой и прочее.
                                          • 0
                                            А еще можно отрыть документацию по BitrixVM и прочитать, что есть файл, в котором можно переопределить все автонастройки БД.
                                            Может не стоит опираться ТОЛЬКО на опыт, а изредка открывать документацию?
                                            • 0
                                              Конечно же всё можно, и скрипт отключаем. Только вот приличные люди в автогенерируемых файлах обычно явно пишут о том, что они автогенерируемы и могут быть затёрты.
                                              • 0
                                                это написано в официальном курсе в разделе по виртуальной машине!

                                                dev.1c-bitrix.ru/learning/course/?COURSE_ID=32&LESSON_ID=3373

                                                там и про затирание, и про переопределение.

                                                PS найдите такие же внятные курсы от разработчиков для joomla )
                                        • –1
                                          В Битриксе увидел полезный модуль — управления рекламными компаниями, баннеры, статистика и тд
                                          (в друпале пока не нашел аналога)
                                          • 0
                                            Поделюсь собственным опытом с точки зрения достижения цели — запустить интересный кастомный интернет-проект в срок и без геморроя. На Битрикс — запустил успешно десятки проектов в разных компаниях и клиенты как правило оставались довольны. Но когда выбирали для реализации фреймворки типа Symfony, ZendFramework — разработчики сразу радовались, но проекты либо не запускались, либо запускались с адским срывом сроков.

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

                                            По поводу миллионов элементов в инфоблоках… Позвольте — но если использовать ORM Doctrine будет тоже самое, если не хуже. Для таких случаев обычно используют уже не РСУБД, а что-то вроде Redis, Cassandra. По мне — инфоблоки боевой полезный инструмент, решающий 99% задач хорошо.
                                            • 0
                                              Но когда выбирали для реализации фреймворки типа Symfony, ZendFramework — разработчики сразу радовались, но проекты либо не запускались, либо запускались с адским срывом сроков.

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

                                              А фреймворки — это продукт, который рассчитан на длительную поддержку проекта, его развитие и масштабирование, а не «тяп-ляп в продакшен, следующий».
                                              Но, конечно, запускать относительно несложный магазин на Битриксе, чтобы работал долго и чтобы была какая-то поддержка с фиксами уязвимостей от разработчика CMS — самое оно. Своя ниша.
                                              • –6
                                                Не соглашусь по поводу
                                                А фреймворки — это продукт, который рассчитан на длительную поддержку проекта
                                                . В опенсорсе не особо принято и дорого тянуть обратную совместимость фреймворка. Т.е. вы пишите на нем, проходит 2 года и… нужно все нафиг переписывать :-) А секьюрификсы к нему уже никто не выпустит — дорого это, обновляйтесь и ПЕРЕПИСЫВАЙТЕ код.

                                                В Битрикс, по опыту, на обратную совместимость тратится куча сил и проекты, написанные 5-7 лет назад — запускаются на новом ядре. Так принято вообще в мире enterprize — поддерживать софт, в который вложены деньги.
                                                • 0
                                                  Т.е. вы пишите на нем, проходит 2 года и… нужно все нафиг переписывать :-)

                                                  Yii 1.1 вышел в 2010 году. Поддержка закончится только в 2015. Но это плохой пример — там действительно всё сломают уже с 2016 (6 лет, да).
                                                  Можно посмотреть на LTS релизы Symfony, где не два года, а четыре (можно выбрать тут текущий LTS 2.7). При этом есть ещё BC promise, согласно которому вам потребуется минимальное количество правок при переходе на другую минорную версию, если они вообще понадобятся.
                                                  Так принято вообще в мире enterprize — поддерживать софт, в который вложены деньги.

                                                  Ещё в мире Enterprise принято актуализировать кодовую базу на долгосрочных проектах.
                                                  Хотя я, конечно, не умаляю заслуг Битрикса в его нише и в маркетинге.
                                                  • 0
                                                    К сожалению, не успел поправить коммент так, чтобы мысль была выражена правильнее, поэтому допишу тут.
                                                    … Ещё в мире Enterprise принято актуализировать кодовую базу на долгосрочных проектах. Тут встаёт логичный вопрос: зачем брать Symfony, если вы не готовы поддерживать свой код? У всех инструментов свои цели. Нельзя пихать везде Битрикс ровно так же как и нельзя всё писать на фреймворках.
                                                    • 0
                                                      Согласен, да. Нужно выбрать верный инструмент, рассчитать затраты и риски. Но всегда иметь перед глазами цель, конечно.
                                                    • 0
                                                      По слухам Yii 1.x продлят и на 2016 +)
                                              • +3
                                                Вы точно понимаете разницу между CMS и фреймворком? И то, что это инструменты для решения совершенно разного уровня задач?
                                                • –3
                                                  Разумеется, это очень разные вещи. Продукт содержит рецепты для решения бизнес-задачи, а фреймворк — чаще рецепты и паттерны для решения более низкоуровневых технологических задач. С точки зрения начинающего разработчика всегда интереснее поучиться новому, изобрести велосипед или достроить хвост фреймворк. Продукт для изучения программирования часто, но не всегда, скучен, т.к. почти все сделано до тебя и остается только работать с API.

                                                  Но чем опытнее разработчик, тем, субъективно, как правило, он все чаще выбирает готовые продукты или решения, чем занимается изобретением велосипедов в рабочее время.
                                                  • +3
                                                    К сожалению, товарисч не понимает разницы. :)
                                                    • –2
                                                      Не могу судить как вы, на сколько «товарисч» понимает разницу по этому его сообщению, но «товарисч» явно знает толк в зарабатывании денег. Речь идет о том, что для абсолютного большинства бизнес задач есть готовые или почти готовые программные решения. Но обычно рпограммисту лень/не интересно разбираться и он мутит велосипед.
                                                    • +3
                                                      Извините за строгость суждений, но у вас «CMS головного мозга».
                                                      У вас практически в каждом комментарии «велосипед, переписывать, маструбация» про фреймворки, и «успешные проекты точно в срок» про битрикс. Выводы делайте сами.

                                                      И все это конечно очень грустно — ведь за пределами php и типовых интернет-магазинов — лежит огромный и увлекательный мир веб-разработки
                                                      • –2
                                                        Именно, Вы совершенно правы. Нет ничего ужаснее услышать от коллеги «увлекательный, огромный мир веб-разработки» в момент, когда нужно писать простой и работающий код, а не городить деревья иерархий и учиться на боевом проекте применять шаблоны проектирования. А потом вдохновенные люди, наигравшись и запутавшись — увольняются, и остаются простые парни, выводящие проект к сдаче кровью и потом :-)
                                                        • +1
                                                          1. Нанять неопытных студентов за копейки.
                                                          2. Пустить их писать на фрейморке типовой магазин.
                                                          3. Вместо контроля за работой и постановки конкретных задач дать им заниматься чем попало.
                                                          4. Завалить сроки.
                                                          5.???
                                                          6. PROFIT

                                                          Я все правильно понял?
                                                      • 0
                                                        Но чем опытнее разработчик, тем, субъективно, как правило, он все чаще выбирает готовые продукты или решения, чем занимается изобретением велосипедов в рабочее время.

                                                        Во-первых, готовые продукты берут даже джуниоры, чтобы меньше тратить времени (если случается ситуация, что джуниору поручают небольшой проект целиком).
                                                        Во-вторых, чем опытнее разработчик — тем лучше он понимает, когда брать готовый продукт, а когда нет. Чаще всего это выражается в покрытии готовым продуктом требований заказчика и количестве/сложности нестандартных требований. Хотя, конечно, есть ещё ситуации, где есть рамки бюджета и как ни крути, а кастомный проект туда не вписать — тогда начинаются доработки готовой CMS, например.
                                                  • +1
                                                    С выводом согласен — очень навороченная система для интернет-магазинов, учтено все, что можно учесть. Для других проектов с большой вероятностью найдутся решения получше.
                                                    Ну а насчет инфоблоков — это плата за универсальность. Посмотрите на тот же друпал или вордпресс (с каким-нибудь acf) — там все так же, кастомные поля хранятся отдельно от постов/нодов/элементов инфоблока. Хотите свою структуру — используйте фреймворки.

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