Как стать автором
Обновить

Комментарии 67

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

Но вот двухсмысленные намёки на репутацию весьма неприятны, она точно заслуженная
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=
Думаю, треть претензий там надуманные и уже исправлены, но представление уже можно составить.
Лично меня там убивает создание страниц в файловом варианте через index.php (— а почему я должен создавать именно index.php в этой папке, товарищ программист? ) и визуальник, который тянется с 2007 года.
А какой файлик вы хотите создавать в папке? Вы можете создать любой(хоть mega-page.php), это же просто файловая структура. А index.php это просто настроены веб-сервера на обработку именно index.php по-умолчанию.
Я для себя решил и всем рекомендую так делать — работать только с разделами(папки с index.php внутри). Непонятностей и проблем меньше(с теми же хлебными крошками).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


Это значит что для каждого типа свойства каждого инфоблока в БД появится отдельная таблица:
Значения свойств хранятся в 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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Публикации