Предыстория, которую можно не читать
Давным-давно, когда словосочетание «web 2.0» было модным, а тени с округлостями были верхом дизайнерской мысли, нашей организации понадобилось упорядочить общение с клиентами и завести себе HelpDesk. И как это обычно бывает, работы по выбору, установке, настройке и внедрению были поручены автору затеи, то есть мне – рядовому сотруднику техподдержки.
Навыки программирования у меня на тот момент были исчезающее малы – немного ковыряния в вордпрессе и пара бесполезных «Hello World!» написанных в Notepad++. И вот с этим багажом знаний я свободное от звонков время стал читать мануалы к имеющимся на рынке на тот момент системам HelpDesk и ServiceDesk.
Битрикс казался наиболее понятной, достаточно полно документированной и простой в установке системой, в которой помимо самого HelpDesk были еще другие полезные плюшки, вроде CMS =) Остальные системы были на тот момент либо на басурманских языках, либо непонятно каких денег стоили (цен на сайтах не было), либо требовали сурового бородатого напильника для доведения до ума.
Так вот к чему это я. Мы выбрали редакцию 1С Битрикс – Управление сайтом (БУС на местном сленге) не для интернет магазина. И модуль интернет магазина никогда не использовали (почти). Этот факт сильно сказался на «пользовательском опыте», каким образом – опишу ниже.
Факт 1. Битрикс: Управление сайтом ? Интернет магазин
Даже если ничего не знать о внутренностях битрикса и не разу не заглядывать в админку, то просто просмотрев содержание всех презентаций и конференций их маркетологов за последние 5 лет легко понять, что кроме модуля интернет магазина ничего особенно и не развивается.
Все новые громкие плюшки вроде фасетных индексов, конверсий и всяких сомнительных мобильных приложений это всё для интернет магазина. Каждый раз когда я смотрю вебинар от битрикса, я чувствую что меня обманули, т.к. кроме разнообразного жонглирования заказами и размусоливания статистики по ним ничего нового в CMS за несколько лет не произошло.
Где-то внутри появилось «ядро 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 таблицы, не меняющиеся при изменении структуры данных: типы объектов, экземпляры объектов, свойства объектов и значения свойств объектов.
Если перевести с языка документации на пользовательский это грозит вот чем: каждое свойство инфоблока будет храниться в отдельной таблице и чтобы его получить понадобится отдельный запрос к базе данных.
Этот подход не доставляет проблем при небольшом количестве записей (зависит от настроек и производительности сервера базы данных) Но когда записей становится несколько миллионов, появляются запросы исполняющиеся за неприличное время. И чем дальше, тем более неприличным это время становится.
Проблему можно решить хорошим производительным сервером БД с правильным конфигом и индексами. Но серебряной пули тут нет, техподдержка не поможет и на форумах информации не так много. Всё придётся делать самостоятельно: анализировать, профилировать и принимать решения.
Есть еще конечно высоконагруженные инфоблоки, но они пока не документированы. Живых примеров по ним мало. И переносить на них несколько десятков инфоблоков с кучей свойств задача не из простых.
Вывод: если у вас нет штатных специалистов по БД, а данных может появиться много, то лучше подумать над выбором других CMS с более оптимальной структурой хранения данных, ну или заложить в проект услуги по настройке БД.
Факт последний. НЕНАВИСТЬ!
Битрикс обладает очень своеобразной репутацией. Очень многие разработчики относятся к нему скептически. Многие разработчики обладают на него аллергией, а некоторые так и вообще ненавидят.
Очень многие студии гордо заявляют что они не работают с битриксом. В курилке этих студий ходят легенды про то «как я поддерживал один проект на битриксе».
Вероятно, благодаря этой репутации работники веб студий изначально скептически относятся к заказам связанным с битриксом и выполняют их не лучшим образом. Тут может сказаться некоторая сложность для новичка, т.к. не все вещи в битриксе устроены очевидным образом и многие задачи можно выполнить сотней неправильных или неоптимальных решений.
Вывод: выбирая битрикс в качестве CMS нужно учитывать его репутацию в IT сообществе и тщательно выбирать исполнителей. Ну и морально подготовиться к тому, что в некоторых местах вас будут отговаривать от его покупки, а после покупки могут уговаривать отказаться от него.
Общий вывод
Если вы не планируете пользоваться модулем интернет магазина, но планируете создать популярный динамичный сайт, то битрикс с этим справится. При этом нужно учитывать, что количество накладных расходов может быть больше чем при выборе другой системы. Лучше внимательно взвесить все за и против.
Комментарии (67)
vanxant
20.07.2015 00:05Ну, не знаю на счет репутации «у работников веб-студий». Как только ценник за сайт переваливает за стоимость пиццы на неделю, так сразу овербольшинство студий оказываются партнерами этого самого битрикса.
Добавлю также, что с интернет-магазином тоже не все айс. С подписками, с аффилиатной программой и т.д. — для галочки есть, по факту долго курим код на предмет «почему не работает». Но конкретно для сайта типа каталог товаров и/или интернет-магазин все отлажено, документировано, интегрировано и по факту — ничего более лучше адаптированного к нашим просторам нет.
AmdY
20.07.2015 00:14-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=
Думаю, треть претензий там надуманные и уже исправлены, но представление уже можно составить.
Alexufo
20.07.2015 00:23+2Лично меня там убивает создание страниц в файловом варианте через index.php (— а почему я должен создавать именно index.php в этой папке, товарищ программист? ) и визуальник, который тянется с 2007 года.
proxaoc
20.07.2015 08:35+3А какой файлик вы хотите создавать в папке? Вы можете создать любой(хоть mega-page.php), это же просто файловая структура. А index.php это просто настроены веб-сервера на обработку именно index.php по-умолчанию.
Я для себя решил и всем рекомендую так делать — работать только с разделами(папки с index.php внутри). Непонятностей и проблем меньше(с теми же хлебными крошками).
У каждой CMS свои особенности, которые надо учитывать.
И визуальный редактор за последние пару лет уже раза два переделали.Alexufo
20.07.2015 11:04+3Так в том то и дело что это не «просто». Вы предлагаете изначально логичный вариант, который решает технические проблемы и который должен быть по умолчанию, раз вы его повторяете регулярно. Эволюция систем в том и состоит, чтобы выбирать лучшие решение в разных ситуациях.
Битрикс забил на контент менеджеров практически сразу со своего создания. Ибо они в прекрасной коммерческой модели битрикса вообще никто. Они не внедряют, не покупают, не продают, не обучают. Они самые конечные пользователи и не имеют права возмущаться ибо им тупо дают логин и пароль. Максимум ссылку на обучалку.
Я не хочу вообще создавать файлов, которые нужно помещать в папки. Это обязывает объяснять пользователям файловую структуру сервера (причем линукса, да, есть и другие операционные системы, а операционная система это вот среда где...), что такое папки и типы файлов, запускаемые по умолчанию при обращении сервера к директории. В некоторой степени это вообще просто смех. Какое отношение это имеет к выполнению задачи, «написать про Васю вот чтобы тут открывалось». У людей мозг взрывается от объяснений.
Многие очевидные вещи для программиста битрикс обязывает обучать секретаршу тулгорводоканала. У них округляются глаза, а почему «Index.php»? А по русски писать нельзя?
Отдельный разговор о «вставка из ворда». Многие пишут изначально в нем, потом шеф утверждает и это переносится на сайт. Я не хочу объяснять почему с ворда тянется куча тегов, я не хочу объяснять что такое теги вообще. CKeditor это делает по умолчанию, все что не в html5 вырезается. Он в своей третьей версии тоже имел кнопку «вставка из ворда». А в 4-ой я ее искал искал пока меня не озарила гениальность сего решения:-)
Типичные задачи пользователя в битриксе не сделаны просто в рамках особенностей cms. Так как особенность подразумевает какое то поведение и движение в своих уникальных рамках. А их тут нет. Визуальник как я видел в 2007 так он такой и остался. :-)proxaoc
20.07.2015 11:19Сначала вы пишете про " создание страниц в файловом варианте", а потом «Я не хочу вообще создавать файлов, которые нужно помещать в папки.». Вы уж решитесь в каком режиме вы работаете в админке :) Там даже где то в настройках есть галочка типа «убрать пункт Файл и папки» и ни вы, ни секретарша из Тулгорводоканала никогда не столкнетесь с index.php
«Битрикс забил на контент менеджеров практически сразу со своего создания. „
Не согласен. Как раз для контент-менеджеров сделано много, я б даже сказал, что местами слишком(кастомные стили для виз.редактора, визуальное редактирование настроек компонентов и т.п.).
Виз.редактор они в новой версии, говорят, сильно допилили. Про вставку из Ворда тоже говорили.
А насчет автоматической очистки от лишних тегов — ох сложная тема. Вот так настроишь очистку, а потом претензии — “я вот 3 часа игралась со шрифтами и цветами, а они на странице выглядят по другому». Лучше сразу объяснять как правильно делать.
«Визуальник как я видел в 2007 так он такой и остался. :-)»
Попробуйте обновить вашу редакцию Битрикса :) все таки даже Битрикс за 8 лет существенно изменился, хотя бы внешне )Alexufo
20.07.2015 16:14-1Битрикс хранит содержание страниц в файлах с возможностью перемешки php — отсюда и все вытекающие минусы.
Объяснения файловой системы, правильных имен файлов, кириллицы от латиницы, что к созданию страниц, как сущности, не имеет отношения.
Вы описываете визуальник битрикса как будто он такой один :-). CKEDITOR по удобности настройки и работы для меня вне конкуренции с битриксовым. Посмотрим что они там допилили. Вау, последний апдейт — наконец то обновили визуальник, прям не верю. С 2007 года он менялся до последнего релиза.
Автоматическая очистка тегов обязательна, поскольку <font attr=«MSO-Tahoma или какой то то там ужас все равно браузером не воспроизводится а в коде он находится. Лучше конечно сразу объяснить, как делать. Тока лучше чем парсер этого не объяснить :-)
proxaoc
20.07.2015 11:29+2Еще раз посмотрел админку Битрикса… Действительно там все таки участвует понятие папки, а не раздела. Просто привык работать из публичной части сайта.
Ну буду спорить. Многим не нравится интерфейс админки Битрикса. Да в нем есть свои заморочки. Но по совокупности, мне кажется все таки юзабилити получше будет, чем у многих. Работал и с Вордпрессом, и Джумлой и Друпалом немного.
jmaks13
21.07.2015 03:17+1Если вы посмотрите как написаны шаблоны битрикса, (яркие представители это шаблоны магазина, каталог например), то там сам чёрт ногу сломит. Я по себе знаю все это, делал не только магазины, но и типовое решение для маркетплейс.
При чем каждый шаблон это «новая история», иногда кажется, что программистам битрикса запрещают общаться друг с другом.
Ну и конечно организация работы с БД, это песня. Я конечно понимаю, что они пытаются поддерживать старые версии битрикса, чтобы обновить всегда можно было, но по моему личному мнению давно пора выпустить совершенно новую версию битрикса с нормальной организацией БД.
И это далеко не все, но конечно есть и плюсы, но их видят в основном только те кто продаёт систему или кто просто не видел ничего лучше этой системы.
customtema
20.07.2015 01:47+2Много лет наблюдаю за этим проектом. Впечатление, в общем, не изменяется: ребятам дают бюджеты «на разработку», они их добросовестно «осваивают».
Командует тот, кто дает бюджеты. Те, кто осваивают — с большим энтузиазмом отчитываются. За освоение.
Дистрибутивы битрикса всегда были монструозны. В сравнении с любым другим из сотен аналогичных продуктов, при идентичной функциональности, реально огромные дистрибутивы.
О чем это может говорить?
ustasby
20.07.2015 02:33-1Нужно просто иметь мозг и не слушать маркетологов, хотя это наверно в другой галактике. А по факту, бюджеты большие, рабы на фрилансе дорогие, откаты не маленькие. В целом все печально.
skobkin
20.07.2015 05:51С битриксом есть ещё такая проблема, что часто им занимаются студенты, которые пришли в какую-нибудь веб-студию поработать на практику.
Есть и более опытные разработчики под Битрикс, которые либо не понимают, куда можно расти дальше, либо работают по принципу «нас и здесь неплохо кормят».
И если попасть ко вторым с заказом — это ещё более-менее нормально, то первые будут радовать результатами раз за разом.proxaoc
20.07.2015 08:42+1Опыт важен в любой работе. Новички косячат везде.
«которые либо не понимают, куда можно расти дальше»
а куда расти опытному программисту на Битриксе вы посоветуете? Больше языков хороших и разных? Есть мнение, что неплохо бы знать о многих технологиях(за всем не успеешь), но быть экспертом в какой то узкой нише.skobkin
20.07.2015 11:58+1Не с моим опытом советы раздавать, выше описанное — это наблюдения со стороны нескольких лет работы, в том числе и в веб-студии. Но для себя решил, что Битрикс — тупик. Там довольно старая кодовая база, чему-то новому там быстро становится сложно учиться. Сам сейчас работаю с Symfony. Хоть фреймворк и очень нравится, но в перспективе хочу смотреть на другие языки, так как PHP пока что не очень приспособлен к решению некоторых задач (есть всякие ReactPHP, но это немного не то).
Опыт важен в любой работе. Новички косячат везде.
Тут вопрос к бизнесу: насколько он хочет, чтобы именно на его сервисах новички получали опыт.
Есть мнение, что неплохо бы знать о многих технологиях(за всем не успеешь), но быть экспертом в какой то узкой нише.
Ну, это что-то близкое к тому, что я имел в виду под «нас и здесь неплохо кормят». Можно обосноваться в популярной нише и заниматься более-менее похожими вещами, получая стабильный доход.
Я не вижу ничего страшного в этом. Это скорее всего рано или поздно в любом случае произойдёт. Только не у всех с Битриксом и не у всех с PHP.
Чтобы не было недопонимания, уточню: я PHP люблю, а не ненавижу как многие, но и недостатки его понимаю.
jmaks13
21.07.2015 03:28Правильно, выберите нишу, решите для себя чем хотите заниматься. Битрикс это однозначно тупик. Сейчас я выбрал для себя nodejs angular mobgodb, ну и go в перспективе и чем больше углубляюсь в этом направлении, тем больше жалею о потраченных годах с битрикс.
proxaoc
20.07.2015 08:49В целом со статьей согласен. Но не согласен, что система слабо развивается. Не все внешне можно увидеть. Очень много возможностей появляется по оптимальной настройке и масштабированию проектов на Битриксе. Очень неплохо за эти пару лет развили свою BitrixVM.
В этом году у Битрикса упор на конверсию, маркетинговые фишки для сайтов. Много улучшений для контент-менеджеров в визуальном редакторе, в обработке картинок для сайта.
Меня, в свою очередь, раздражает, что очевидные ошибки и полезные, нужные предложения(idea.1c-bitrix.ru) очень долго внедряются.
Более 3000 предложений(и ошибок), которые Битрикс сам согласился рассмотреть, и только 200 в работе.skobkin
20.07.2015 12:01+1Похоже, что вы в курсе экосистемы, поэтому спрошу вас, так как самому интересно.
Я когда ещё наблюдал за работой с Битриксом где-то в 2013 году слушал вебинары про разработку на нём и спрашивал у ведущих, как делать в Битриксе миграции. Мне отвечали, что делать их можно инфоблоками или отдельными standalone-скриптами.
Что-то в этом плане поменялось?proxaoc
20.07.2015 12:24+1Мне кажется миграции базы данных вообще сложная тема в любой системе ) Обычно разработчик вручную их создает.
По сути так все и осталось — или экспорт-импорт инфоблоков(xml) или свои скрипты с использованием API Битрикса, ну или ручная синхронизация :)
По крайней мере я больше вариантов не видел.skobkin
20.07.2015 13:20+1Ясно, спасибо. Жаль, что ничего не изменилось.
mvs
20.07.2015 15:29Про миграции есть кое-что интересное от сторонних разработчиков: раз, два. Я лично обхожусь пока что самописным скриптом для автоматизации.
t0H
20.07.2015 09:53Инфоблоки — сущность, которая в физической структуре БД создает 4 таблицы, не меняющиеся при изменении структуры данных: типы объектов, экземпляры объектов, свойства объектов и значения свойств объектов.
В настройках каждого инфоблока есть волшебный пункт — «где хранить данные: в общей таблице или отдельной». собственно эта настройка появилась там уже как 3-5 лет (точно не помню), но ваш этот минус нивелирует полностью… Хотя бы из одного этого видно как вы читаете документацию и тем более, как качественно, вы освоили курсы Битрикса… А они весьма подробные и исчерпывающие…
murzix Автор
20.07.2015 10:53+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
Печалька начинается когда нужно получить данные из нескольких связанных инфоблоков. При большом объеме данных это очень небыстро.t0H
20.07.2015 11:00+1Ну значит это проблема не инфоблока, а неверной реализации задачи…
В любой CMS есть возможность писать свои модули… и Битрикс не исключение…
Изначально инфоблоки это представление данных, для новостей и магазина… Собственно с этим то онии как раз замечательно и справляются… Для остального можно написать свой модуль со своей таблицей, которая будет сделана идеально под конкретную задач…
Нельзя и рыбку съесть, и на… й сесть) В плане удобства и универсальности одновременно, всегда надо чем то жертвовать((murzix Автор
20.07.2015 11:08+1Весь наш код вынесен в модули. Без этого не получится нормально кешировать всё что нужно и будет плодиться постоянный копипаст. по-моему, так делают все.
А по по поводу таблиц. Главный плюс инфоблоков — разруливание прав и интерфейс админки. Если от всего этого отказаться, то зачем тогда битрикс?t0H
20.07.2015 11:18-3У битрикса есть подробнейшая инструкция по созданию собственных модулей (и компонентов) собственно там же есть инструкция по организации разграничения прав…
Кеширование делается вообще в один присест… И все нормально делается… надо вам кешировать html пожалуйста, надо только данные, так же просто… Нужно чтобы кеш зависел от каких то эфемерных параметров (дата, ID пользователя, фаза луны) тоже элементарно.
То, что вы будете делать свой модуль с блекджеком, и всем причитающимся, не отменяет всех фишек битрикса… )
И даже больше свой собственный модуль позволит сделать более удобное меню в админке, сделать свою страницу настроек, если это необходимо…
Ну и главное, что для этого есть документация… да она не всегда актуальна, но она есть и не надо искать на каких то непонятных сайтов любителей инструкцию…
Ну и + если вы сделаете какой-то реально охрененный модуль, вы можете его продать еще раз через маркетплейс…
WorksIsGone
20.07.2015 14:50>Изначально инфоблоки это представление данных, для новостей и магазина… Собственно с этим то онии как раз замечательно и справляются…
Расскажите, как с помощью замечательно справляющихся инфоблоков сделать
новости на четрырёх языках. И так, что бы ссылка на прошлую новость показывалась в том же языке.
Забивать ид ручками в новости не предлагать.t0H
20.07.2015 15:00+1Самый просто вариант — сделайте 4 инфоблока и подключайте нужный в зависимости от языка. А используя ЧПУ адрес будет всегда одинаковый… никаких ID
Есть такое поле как CODE его можно использовать как адрес.WorksIsGone
20.07.2015 15:10-1Как определить, какой нужный? В этом-то и был вопрос.
Как может быть одинаковый адресс у разных новостей?
+ учитывайте древовидность, связи раздел-подраздел-новость
ссылку по верхним связям тоже должны быть интернационализованы,
что бы нажимая на «news» пользователь не попадал в «новости»t0H
20.07.2015 15:18Адрес страницы может автоматически генерироваться из например заголовка…
Тоетсь новости могут иметь один и тот же url, а на основании него и языковой константы будет подбираться инфоблок… не вижу проблемы в том чтобы новости дать 1 и тот же адрес…
То есть новость с заголовком «Новость» будет иметь поле CODE = news
C заголовком «News» — тоже news
И так далее…
Это поле может генерироваться битриксом автоматически и если ваш редактор не будет придумывать РАЗНЫЕ заголовки для новостей на разных языках… то и адреса будут одинаковые…
А учитывание древовидности — #SITE_DIR#/folder/#SECTION_CODE_PATH#/#CODE#/
p.s. не утруждайся ответом. у тебя видно же цель — доебаться и показать что битрикс говно… и на нем даже такую простую задачу не реализовать, лучше использовать «вписать название фреймворка, CMS»…WorksIsGone
20.07.2015 15:38+2Я вроде вам не тыкал, но это ничего, да. Сейчас модно-молодёжно так.
Продолжайте в стиле #php (=
Ничего, что slug-ги вообще-то тоже хорошо бы интернациолизировать?
Что бы не было смешных казусов когда слово-фраза смешно звучит в другом языке?
>Тоетсь новости могут иметь один и тот же url, а на основании него и языковой константы будет подбираться инфоблок…
Как вы будете хранить привязку инфоблок — язык?
В четырёх вариантах?
У меня на тот момент, не нашлось другого решения, как сделать таблицу трансляций, хорошо инфоблоков было по
штук 20 всего.
По таблице я всегда мог рассчитать линку на правильный инфоблок в любом языке.
Но если б там было 1000 блоков?
Еще, тех же времён проблема — получить список стран.
GetCountryArray в забавном виде отдавала список, а GetCountryByID толи небыло толи не работало.
>p.s. не утруждайся ответом. у тебя видно же цель — доебаться и показать что битрикс говно… и на нем даже такую простую задачу не реализовать, лучше использовать «вписать название фреймворка, CMS»…
Нет, что Вы! Моя цель показать, что битрикс всегда был на грани прогрессивных решений и внедрений новых концепций! Это был самый совершенный продукт с которым я столкнулся.
Одно количество файлов, сгенерированных белковыми искусственными(?) интеллектами чего стоит.
Слава роботам!t0H
20.07.2015 15:40Ну о чем я и говорил…
Можно было не тратить байты, позиция была изначально ясна…
p.s. дичайше извиняюсь за «ты», свет от Вашей короны меня слегка ослепил и меня бес попутал… )
t0H
20.07.2015 15:18Адрес страницы может автоматически генерироваться из например заголовка…
Тоетсь новости могут иметь один и тот же url, а на основании него и языковой константы будет подбираться инфоблок… не вижу проблемы в том чтобы новости дать 1 и тот же адрес…
То есть новость с заголовком «Новость» будет иметь поле CODE = news
C заголовком «News» — тоже news
И так далее…
Это поле может генерироваться битриксом автоматически и если ваш редактор не будет придумывать РАЗНЫЕ заголовки для новостей на разных языках… то и адреса будут одинаковые…
А учитывание древовидности — #SITE_DIR#/folder/#SECTION_CODE_PATH#/#CODE#/
p.s. не утруждайся ответом. у тебя видно же цель — доебаться и показать что битрикс говно… и на нем даже такую простую задачу не реализовать, лучше использовать «вписать название фреймворка, CMS»…
djem
20.07.2015 09:55+4Косяков на самом деле гораздо больше, чем раскрыто в статье. Но и достоинств тоже есть. Для себя формулирую отношение к этой CMS как «приятно делать из говна конфетку». Эта формулировка остужает и расставляет всё на свои места.
У меня за плечами опыт разработки буквально любого ПО на тьме языков, архитектур и инструментов. И я могу сказать, что посты ненависти легко можно написать про всё. Буквально вообще про всё. А вот научиться выбирать и, главное, потом использовать инструмент правильно — гораздо, несравненно более сложно.
В целом, если понять о чём думали или не думали разработчики того или иного инструмента, понять внутреннюю архитектуру в ретроспективе и динамике развития, то вполне можно писать правильно с точки зрения данной архитектуры. И это будет приятно, даже если с точки зрения другой архитектуры это бред сивой кобылы. И это тоже применимо ко всему.
Хватит жаловаться. Просто делайте свою работу, это далеко не самая ужасная работа на свете. ;)jmaks13
21.07.2015 04:45+1«приятно делать из говна конфетку».
Полностью согласен, но когда делаешь конфетку из шоколада, а не из похожей только по цвету консистенции, это гораздо приятнее.
nikolayvaganov
20.07.2015 10:47+8Не холивара ради, но для полноты картинки, вставлю свои пять копеек как сисадмин Linux.
1. Для нормальной работы Битрикса требуется действительно быстрая машина, а если посетителей на сайте будет больше одного, то еще и на ssd. Одна из самых тяжелых CMS ( если не самая тяжелая ), в стандартной поставке — установил и работай производительность просто никакая.
2. Попугаи в панели производительности. Вот примерный сюжет ( з — заказчик, а — администратор ):
з. Вот вам деньги, оптимизируйте сервер под битрикс
а. Готово, все кешируется нужное время, админ панель не кешируется, настройки сервера оптимальные
з. Ничего не готово. Я купил сервер за 200$ в месяц, в панели производительности стоит 50 вместо эталона 30, я хочу 120. У моего друга все быстрее, он платит всего 100$ а попугаев 56. Работа не выполнена, никаких денег, держите злобный отзыв.
а. Битрикс работает быстро? Страницы открываются быстро?
з. Да быстро, но не доволен производительностью, до свидания.
ValdikSS
20.07.2015 12:32Назад-то все вернули?
nikolayvaganov
20.07.2015 15:21+1Естественно, если заказчик полностью отказывается от оплаты, сразу же откатываю настройки к стандартным ( опыт научил делать бекап конфигов до начала изменений ), сообщаю об этом и удаляю публичный ключ с сервера.
KawaiDesu
20.07.2015 14:33+1Как такой же сисдамин подпишусь.
У битрикса очень многое упирается в базу. Если она нормально настроена и вся влезает в память (innodb), то сайт достаточно шустрый и без всяких SSD. Бывают, конечно, случаи говнокода при разработке, которые тормозят весь движок, но это отдельная песня.
Конечно, попугаи производительности так ещё ш(ут|ту)ка. Как и провещик конфигурации. Например, эта скотина отправляет почту, где в качестве домена отправителя использует hostname машины, с чем частенько категорически не согласен opensmtpd (кривой отправитель). А так же весёлые настройки размера стека и прочие шалости.
Отдельно доставлял (не знаю, как сейчас, сталкивался с этим моментом 3 года назад) скрипт-автооптимизатор в автозагрузке их официального центосёвого образа, который вычисляет «оптимальные» параметры (основываясь на размере памяти машины) для MySQL и выставляет их при каждой загрузке. И срать он хотел, что ты там наоптимизировал, если забыл выключить этот скрипт.nikolayvaganov
21.07.2015 08:28Если Вы работали с битриксом больше одного раза, то знаете великолепную формулу, по которой высчитываются попугаи ( 1 / Среднее время отклика ). В этой формуле не учитывается скорость работы с базой и прочее.
Legh
21.07.2015 17:47А еще можно отрыть документацию по BitrixVM и прочитать, что есть файл, в котором можно переопределить все автонастройки БД.
Может не стоит опираться ТОЛЬКО на опыт, а изредка открывать документацию?KawaiDesu
21.07.2015 17:51Конечно же всё можно, и скрипт отключаем. Только вот приличные люди в автогенерируемых файлах обычно явно пишут о том, что они автогенерируемы и могут быть затёрты.
Legh
21.07.2015 17:55это написано в официальном курсе в разделе по виртуальной машине!
dev.1c-bitrix.ru/learning/course/?COURSE_ID=32&LESSON_ID=3373
там и про затирание, и про переопределение.
PS найдите такие же внятные курсы от разработчиков для joomla )
Valeratal
20.07.2015 11:54-1В Битриксе увидел полезный модуль — управления рекламными компаниями, баннеры, статистика и тд
(в друпале пока не нашел аналога)
AlexSerbul
20.07.2015 12:12Поделюсь собственным опытом с точки зрения достижения цели — запустить интересный кастомный интернет-проект в срок и без геморроя. На Битрикс — запустил успешно десятки проектов в разных компаниях и клиенты как правило оставались довольны. Но когда выбирали для реализации фреймворки типа Symfony, ZendFramework — разработчики сразу радовались, но проекты либо не запускались, либо запускались с адским срывом сроков.
Почему? Потому-что Битрикс это рожденный потом и кровью абсолютно приземленный и приспособленный решать практические насущные задачи продукт, а фреймворки нередко плод технологическо-интеллектуальных мастурбаций, больше подходящий для научно-исследовательских целей, чем для «запустить точно в срок».
По поводу миллионов элементов в инфоблоках… Позвольте — но если использовать ORM Doctrine будет тоже самое, если не хуже. Для таких случаев обычно используют уже не РСУБД, а что-то вроде Redis, Cassandra. По мне — инфоблоки боевой полезный инструмент, решающий 99% задач хорошо.skobkin
20.07.2015 13:27Но когда выбирали для реализации фреймворки типа Symfony, ZendFramework — разработчики сразу радовались, но проекты либо не запускались, либо запускались с адским срывом сроков.
Может быть, команда и менеджмент не были к этому приспособлены? Потому, что я наблюдал подобный опыт, но это практически всегда следовало из того, что заказчику назывались сроки разработки не кастомного, а гораздо ближе к типовому решения.
а фреймворки нередко плод технологическо-интеллектуальных мастурбаций, больше подходящий для научно-исследовательских целей, чем для «запустить точно в срок».
А фреймворки — это продукт, который рассчитан на длительную поддержку проекта, его развитие и масштабирование, а не «тяп-ляп в продакшен, следующий».
Но, конечно, запускать относительно несложный магазин на Битриксе, чтобы работал долго и чтобы была какая-то поддержка с фиксами уязвимостей от разработчика CMS — самое оно. Своя ниша.AlexSerbul
20.07.2015 13:45-6Не соглашусь по поводу
А фреймворки — это продукт, который рассчитан на длительную поддержку проекта
. В опенсорсе не особо принято и дорого тянуть обратную совместимость фреймворка. Т.е. вы пишите на нем, проходит 2 года и… нужно все нафиг переписывать :-) А секьюрификсы к нему уже никто не выпустит — дорого это, обновляйтесь и ПЕРЕПИСЫВАЙТЕ код.
В Битрикс, по опыту, на обратную совместимость тратится куча сил и проекты, написанные 5-7 лет назад — запускаются на новом ядре. Так принято вообще в мире enterprize — поддерживать софт, в который вложены деньги.skobkin
20.07.2015 14:24Т.е. вы пишите на нем, проходит 2 года и… нужно все нафиг переписывать :-)
Yii 1.1 вышел в 2010 году. Поддержка закончится только в 2015. Но это плохой пример — там действительно всё сломают уже с 2016 (6 лет, да).
Можно посмотреть на LTS релизы Symfony, где не два года, а четыре (можно выбрать тут текущий LTS 2.7). При этом есть ещё BC promise, согласно которому вам потребуется минимальное количество правок при переходе на другую минорную версию, если они вообще понадобятся.
Так принято вообще в мире enterprize — поддерживать софт, в который вложены деньги.
Ещё в мире Enterprise принято актуализировать кодовую базу на долгосрочных проектах.
Хотя я, конечно, не умаляю заслуг Битрикса в его нише и в маркетинге.skobkin
20.07.2015 14:29К сожалению, не успел поправить коммент так, чтобы мысль была выражена правильнее, поэтому допишу тут.
… Ещё в мире Enterprise принято актуализировать кодовую базу на долгосрочных проектах. Тут встаёт логичный вопрос: зачем брать Symfony, если вы не готовы поддерживать свой код? У всех инструментов свои цели. Нельзя пихать везде Битрикс ровно так же как и нельзя всё писать на фреймворках.AlexSerbul
20.07.2015 22:46Согласен, да. Нужно выбрать верный инструмент, рассчитать затраты и риски. Но всегда иметь перед глазами цель, конечно.
xoma
22.07.2015 14:41По слухам Yii 1.x продлят и на 2016 +)
skobkin
22.07.2015 14:42Ужасы опенсорса как они есть.
xoma
22.07.2015 14:43Ну почему ужасы? Тонны кода на Yii 1.х понаписано. И это отлично, что разработчики продлят поддержку.
skobkin
22.07.2015 14:45+1Это была отсылка к:
Т.е. вы пишите на нем, проходит 2 года и… нужно все нафиг переписывать
ftdgoodluck
20.07.2015 13:33+3Вы точно понимаете разницу между CMS и фреймворком? И то, что это инструменты для решения совершенно разного уровня задач?
AlexSerbul
20.07.2015 13:40-3Разумеется, это очень разные вещи. Продукт содержит рецепты для решения бизнес-задачи, а фреймворк — чаще рецепты и паттерны для решения более низкоуровневых технологических задач. С точки зрения начинающего разработчика всегда интереснее поучиться новому, изобрести велосипед или достроить хвост фреймворк. Продукт для изучения программирования часто, но не всегда, скучен, т.к. почти все сделано до тебя и остается только работать с API.
Но чем опытнее разработчик, тем, субъективно, как правило, он все чаще выбирает готовые продукты или решения, чем занимается изобретением велосипедов в рабочее время.
MaZaY_Dead
20.07.2015 15:47+3К сожалению, товарисч не понимает разницы. :)
jrip
20.07.2015 16:44-2Не могу судить как вы, на сколько «товарисч» понимает разницу по этому его сообщению, но «товарисч» явно знает толк в зарабатывании денег. Речь идет о том, что для абсолютного большинства бизнес задач есть готовые или почти готовые программные решения. Но обычно рпограммисту лень/не интересно разбираться и он мутит велосипед.
ftdgoodluck
20.07.2015 22:29+3Извините за строгость суждений, но у вас «CMS головного мозга».
У вас практически в каждом комментарии «велосипед, переписывать, маструбация» про фреймворки, и «успешные проекты точно в срок» про битрикс. Выводы делайте сами.
И все это конечно очень грустно — ведь за пределами php и типовых интернет-магазинов — лежит огромный и увлекательный мир веб-разработкиAlexSerbul
20.07.2015 22:42-2Именно, Вы совершенно правы. Нет ничего ужаснее услышать от коллеги «увлекательный, огромный мир веб-разработки» в момент, когда нужно писать простой и работающий код, а не городить деревья иерархий и учиться на боевом проекте применять шаблоны проектирования. А потом вдохновенные люди, наигравшись и запутавшись — увольняются, и остаются простые парни, выводящие проект к сдаче кровью и потом :-)
skobkin
21.07.2015 02:45+11. Нанять неопытных студентов за копейки.
2. Пустить их писать на фрейморке типовой магазин.
3. Вместо контроля за работой и постановки конкретных задач дать им заниматься чем попало.
4. Завалить сроки.
5.???
6. PROFIT
Я все правильно понял?
skobkin
21.07.2015 14:34Но чем опытнее разработчик, тем, субъективно, как правило, он все чаще выбирает готовые продукты или решения, чем занимается изобретением велосипедов в рабочее время.
Во-первых, готовые продукты берут даже джуниоры, чтобы меньше тратить времени (если случается ситуация, что джуниору поручают небольшой проект целиком).
Во-вторых, чем опытнее разработчик — тем лучше он понимает, когда брать готовый продукт, а когда нет. Чаще всего это выражается в покрытии готовым продуктом требований заказчика и количестве/сложности нестандартных требований. Хотя, конечно, есть ещё ситуации, где есть рамки бюджета и как ни крути, а кастомный проект туда не вписать — тогда начинаются доработки готовой CMS, например.
mr_T
21.07.2015 16:53+1С выводом согласен — очень навороченная система для интернет-магазинов, учтено все, что можно учесть. Для других проектов с большой вероятностью найдутся решения получше.
Ну а насчет инфоблоков — это плата за универсальность. Посмотрите на тот же друпал или вордпресс (с каким-нибудь acf) — там все так же, кастомные поля хранятся отдельно от постов/нодов/элементов инфоблока. Хотите свою структуру — используйте фреймворки.
mmjurov
Битрикс — это не только интернет магазин. Есть ещё Битрикс24, который активно развивается. Чертей своих у него тоже хватает, но потребители жрут его даже за бугром, ведь он такой няшный…
murzix Автор
Битрикс24 это отдельная история. Пользователей БУС она не затрагивает =)
AlexGx
Б24 и семейство битрикс цмс это совсем разные продукты, нельзя их сравнивать.
vanxant
Чем разные?
Вы внутре Б24 ковыряли (коробочную версию, а не облачную)? Обычный битрикс с кастомным решением и модулями.
dunmaksim
Морская свинка какая-то — ни к морю, ни к свиньям отношения не имеет.