Комментарии 58
Не знаю, насколько вам будет интересен этот комментарий, но читается статья тяжело. Я бы охарактеризовал этот стиль как "бессвязно-развязный". Слов очень много, но при этом структура отсутствует как в статье целиком, так в отдельных абзацах. Плюс какое-то фамильярничанье — "пыха", "крыша". И это "Я тут два дня по верхам посмотрела, сейчас буду рекомендации давать!".
При всей нелюбви к Битриксу, читать это всё неприятно.
Спасибо. Очень вас понимаю - и пишется тяжело, и учится. Разве что про "нелюбовь" к нему добавлю два слова.
Я буквально вчера разделила для себя "битрикс как инструмент" и "битрикс как продукт". И как продукт (статья, собственно, о битриксе как продукте скорее) он наглухо абсолютно захватывающий совершенно, только с поллитрой в сутки. В час. Ну то есть... Я в общем в целом не пью, но тут обнаружила, что за мои две недели учёбы практически не выхожу из квартиры даже. А вроде бы лето.
Битрикс - такой Магадан, мне кажется. Там очень много людей. Они очень заняты. Они рассчитывают на Битрикс в его сегодняшнем виде. Они не любят, когда под окнами роют. И не надеются получить местные апельсины (я ничего толком про Магадан не знаю, это только мои фантазии - что своих апельсинов там не выращивают).
А между тем это город с инфраструктурой. Скажем, в Финляндии тоже климат тяжёлый, но есть подход "ок, тут такая задача, как бы саму её постановку бы упростить".
У меня по началу к битриксу вовсе не "нелюбовь" была - это был шок. Шок, продержавшийся почти неделю, с вопросом "куда смотреть-то? Откуда куда бежать и зачем?" Я как-то раз на пассажирском сидении оказалась на МКАДе с водителем-начинашкой, ну и тут с битриксом вспомнила это зрелище: рядом с тобой сидит человек с десятью руками, тремя ногами, двигает сразу всем и не очень вовремя. И очень нервничает. Хуже того: от его этих действий зависит ваше здоровье, как минимум, а то и вовсе - жизнь.
Я правда удивлена, что в сети нету карты файлов "кто кого подключает" для разработчиков. Для освоения старого кода Битрикса. Кто кого подключает, и что где творится на каком уровне. Вот, например, есть массив по имени $aMenuLinks (не спрашивайте), есть $arParams и $arResult. Ну и как они связаны? Где? В каком файле какого уровня? Каким способом?
Как только вы докапываетесь до нужных файлов, Битрикс становится даже не проще - он тривиален. Это длинные простыни разных ифов. Иф то да сё, вот тут вот присвоить так, если нет - то эдак. Если вон там то да сё, то там вон присвоить так-то. Ну и так далее. Ваш арРезалт становится ясным объектом работы, вернее, становится результатом действий какого-то текста из сотни ифов. "Ну хорошо", вы думаете, "пусть их всегда так зовут, результаты, это у них фамилия." Он всегда арРезалт, только состав там разный, в зависимости от компонента.
Ну и в статье идея в том, что отладка поверхности, как бы сказать, на уровне разработчика - это ж не так уж сложно. Вроде бы, так поменять старый код, чтобы разрабы не плакали, в целом просто. Хотя бы отчасти. Ну хоть бы вынести этот чёртов Б_ПРОЛОГ_ТУТ наружу, в секьюрити файл. Чтобы просто на каждом уровне думать о главном - главном для этого уровня, а остальное использовать, но не думая.
...есть ещё версия "мышкой копировать такие строчки". Я так попробовала. С третьего раза взвыла - я не могу так. Если в моей работе есть некий код, я хочу знать, о чём он и для чего. Что за проблему исходно мы им решаем. И почему решаем именно так.
не мучайте себя, проходите мимо, если не нравится. а с БХ наверное есть те кому оно нравится, пусть и занимаются с ним.
Это как приехать в деревню и ходить объяснять местным жителям что этот гнилой сарай надо давно снести. Даже если объективно его и пора бы уже снести.
Я вообще ни разу не говорила, что надо снести сарай. Битрикс - огромный город. И в нём есть места, которые, кмк, сравнительно легко реформировать, сохранив оболочку. Причём реформы в одних местах не затронут другие: можно всё это сделать последовательно, шаг за шагом.
Ну вот вы не говорили, а снести надо бы...)
Вот например как решена довольно старая проблема (спойлер: не решена). dev.1c-bitrix.ru/community/blogs/oracle/2477.php (обратить внимание на комментарии о получении опыта)))
И таких мест множество, взять хотя бы порядок аргументов для множественных файлов, поменял местами VALUE и DESCRIPTION и всё, не работает. Хотя можно просто проверять наличие ключа. И поменять код не сложно, и обратную совместимость не сломает.
У меня есть пару кейсов когда «передано в отдел разработки» с багами, и почти пару лет уже не сделано. А клиент платить за фикс тоже не хочет: «лицензия же, техподдержка же, зачем мне платить ещё раз».
Вам наверное неизвестно что такое "обратная совместимость"
Похоже, я чем-то вас очень задела. Вы прошли по нескольким моим статьям, а чтобы что?
Хуже всего, что вы пишете такое, на что "да знаю я, что такое обратная совместимость" отвечать как-то даже ещё глупее, чем... какие ещё варианты действий возможны-то?..
Похоже, вы искренне любите битрикс - у меня встреча с ним была случайной, в основном - по неведению. И трип уже кончился. Так что, если вы защищаете битрикс, то от меня защищать бессмысленно - мы с ним, видимо, больше не встретимся никогда. Ну или встретимся, но уже очень не скоро.
Абсолютно согласен с комментарием FanatPHP. Материал изложенный вами тяжело даётся для понимания и сути статьи.
Можно было просто сократить до одного предложения: Я решила поучить битрикс и поняла что там ад, но вот держите ссылки где я всего этого набралась.
Я так ничего и не понял. Но я понял хотя бы то, что пример из Laravel некорректен. Ибо метод update у модели принимает только массив $parameters & $options. И не знание основ фреймворка говорит о том, что вы, скорей всего, вообще с ним не работали.
Господи:) Таки да, спасибо больше. Сейчас исправлю (я о примере на ларавель). Я с ним уже пару лет, но просто последние пару недель на битриксе 25 часов в сутки. Это выматывает.
Странно что вас вообще хватило на такое время. Я как узнал какой там творится ад, вообще даже мысли не было к нему притрагиваться. Хотя предлагали и я сразу открещивался от него. Не в обиду битриксоидам. :)
Я, собственно, бросила, видимо. Ещё в задумчивости. В частности, среди целей статьи было понять, стоит ли пробовать в этом вырасти дальше. Ну и ещё себе двухнедельной давности что-то сказать, что упростило бы то ли решение, стоит ли ввязываться, то ли процесс учёбы, раз уж ввязалась уже.
Наверное, сделаю перерыв. А там уже как пойдёт.
Перечитала статью и комментарии, пару часов сознательно отдохнув - впервые за две недели. Читать это невозможно, тут вы все правы:)
Но. В статье всё таки не только "я поняла, что там ад". Я ещё там с гипотезами, где этот ад-то, похоже, на ровном месте выращен. Я просто по второму в/о психолог, несколько лет проработала у Л.Ф. Обуховой на факультете психологии образования в МГППУ. Ну и мне любопытно, как ухитряются люди на ровном месте сделать добавочных три проблемы, решая одну какую-то. Что-то вроде борьбы Ивана со змеем - рубим голову, три вырастает, и так по кругу. Вот уже сто голов, вот уже тысяча, а мы всё мечемся.
Сколько я видела комментариев, что Битрикс - зло. Но никогда не видела ничего по делу. Что надо бы изменить, что причём дёшево поменять, и что, при этом, видимо, упростит работу разрабам, не изменив вообще ничего для контент-менеджеров.
...В свободное время... учить Битрикс... Да ещё и после Laravel... А вы знаете толк в извращениях!
До стх пор помню тот момент, когда после Битрикса попробовал Yii — этот странный восторг от того, что прямо на твоих глазах творится настоящая магия вместо привычной битриксовой имитации.
Имхо, Битрикс — прекрасный трамплин для маркетологов: вот они-то там точно получают мастер-класс. Для программиста же это лимбо.
А можно с вами поговорить как со специалистом?
Как вам вот эта мысль: в Битриксе чуть ли не главное зло - наличие пяти файлов да в трёх местах про одно действие? Причём про каждое это свои три места. Или четыре. Или шесть разных папок новых.
Ровно туда же - "чтобы подправить в коде настройку вызова компонента, надо
вдуматься, какая папка и какой там файл
в вёрстке найти компонент
найти нужный параметр
изменить параметр
Коротко говоря, это, в общем-то, невозможность деления дел на планирование - выполнение - контроль/исправление - и так по кругу.
Если бы, например, настройки вызова компонента жили в БД (а компонент вызывался бы с айдишником строчки в таблице таких настроек), мы бы, меняя настройки, вообще не думали бы про вёрстку. А в момент вёрстки вообще не думали бы о настройке - вёрстка осталась бы только про расположение внутри страницы.
Если эта формулировка вам кажется спорной, можете ли скорректировать её? Или с достаточным опытом это вот всё тут выше - вообще не тема, а Битрикс - лимбо в силу вообще других факторов? А каких?
ЗЫ я сначала-то Yii попробовала. И напряглась от виджетов, не поверите. Это был первый опыт с вёрсткой такого типа, в шаблонах такого уровня. Ну и вот это вот их подключение css... Я тогда, видите ли, ещё не знала про Битрикс. Всё ж познаётся в сравнении - в сравнении с blade вёстка от Yii - это что-то с чем-то.
То что вы описываете, это не проблема Битрикса а это проблема кривых разработчиков на Битриксе, которые начали писать на нём 15 лет назад и продолжают в том же стиле и сейчас.
По факту нормальный сайт на Битриксе сейчас использует D7+ORM. Взаимодействие front и back идет по REST API. Стандартные компоненты не используются. Тогла алгоритм внесения изменений становится прост:
Если это контент, то он правится в соотвествующих модулях админ панели
Если это набор данных, отдаваемый backend на frontend - это правится в коде и шаблоне соотвествующих компонентов.
Если это отображение - это уже frontend и к Битриксу отнешения не имеет.
Битрикс не нужен.
Хостинг для Битрикса все еще дороже чем для всех остальных?
Я уточню только, что в статье не реклама. В смысле что я ни разу не представитель Битрикса. В данный момент у меня в компьютере пробная версия (и скоро кончится), а ещё сервер, только учебный. Сервер от фирмы, где я сейчас учу Битрикс.
Ну и такое. Насколько я поняла из нескольких видео по истории, вроде бы, дело-то не вполне в Битриксе, а в 1С. Был для начала Битрикс просто для сайтов. Дальше они интегрировались с 1С, вышел 1С-Битрикс. И принадлежит 1С. Или там что-то совместное, я не помню. Платят, собственно, именно за интеграцию. То есть, реально движок (как минимум, декларативно) отвечает не только за вывод инфы в сети, но ещё за оплату, налоги, отчётность. И это прям денег стоит реально. Если вы пробовали обращаться к бухгалтеру или юристу, вы сами знаете.
Как в вашей статье и комментариях читать фразу "Ну и такое" или "Кнопка "добавить ссылку на css", такое."? Вроде, ожидается, что будет пример кода, какое именно "такое" это самое "кнопка", но кода нет, это вводит в заблуждение. А самостоятельное предложение "Ну и такое" вообще запутало.
Переводы вида "$_НАЧАТЬ['КОРНЕМ_САЙТА']" трудно переводить обратно. Я распознал document_root, но $_НАЧАТЬ не припомню. Это $_SERVER, $_GET?
Ещё лично меня регулярно сбивал странный порядок слов в предложениях, типа такого: "Что помешало умный редактор сделать слегка иначе". Если читать это слева направо, то сперва читаешь "Что помешало умный редактор", исправляешь в голове на "умному редактору", потом дочитываешь до конца и приходится перестраивать смысл всего предложения заново. Как стихи читаю — большая когнитивная нагрузка. Для восприятия проще такое: "Что помешало сделать умный редактор слегка иначе". Тут "помешало сделать" написано слитно, поэтому не приходится искать смысл по разным частям предложения.
Схожее построение с глаголом в конце есть в предложении "Даже один процент вашего миллиона хитов формировать страницу с нуля не требует". Магистр Йода кумир ваш?
Также глаз зацепился за обилие точек там, где просится запятая: "Минусы такого решения: мы больше файлов проходим при формировании клиентской выдачи. И больше файлов при перенастройке страницы. Но."
А тут слишком много "я": "я обрадовалась: я там увидела ссылочку "карта модулей". Я почему-то решила".
В фразе "Лично мне для учёбы такая бы подошла" я так и не смог понять, кто именно "такая", потому что ближайшее слово женского рода, к которому это может относиться — "ссылочка "карта модулей", но описана явно не ссылочка. И снова глагол в конце, хотя, имхо, проще читается "мне для учёбы подошла бы такая".
// Наверное, мне стоило оформить цитаты цитатынми блоками…
Был для начала Битрикс просто для сайтов. Дальше они интегрировались с 1С, вышел 1С-Битрикс. И принадлежит 1С.
Вроде бы Битрикс никогда не принадлежал 1С. Это совместное предприятие.
То есть, реально движок (как минимум, декларативно) отвечает не только за вывод инфы в сети, но ещё за оплату, налоги, отчётность.
Ну как... Битрикс, который для магазинов (редакции Бизнес), имеет модуль для интеграции с 1C. Так как 1С у каждого предприятия имеет свои особенности конфигурации, нельзя просто взять и настроить этот модуль в админке, чтобы отчётность и склад заработали. Требуется работа по интеграции и стоить она будет прилично. Но далеко не все даже интернет магазины это используют. И есть куча сайтов на Битриксе, которые магазинами не являются и вообще никакую интеграцию с 1С не используют.
А что ещё на нём делают, и каковы тогда мотивы выбора именно Битрикса? Есть, например, бесплатный Вордпресс, он тоже с админкой - если нужна админка.
Это не восклицание, а содержательный вопрос. Мне правда любопытно, чем люди мотивируют такой выбор. Опять же, я не о том, что "Битрикс плохой" - мне почему-то тут в каждом втором комментарии приписывают такое мнение. Я так не говорила. Такая сложная штука не может быть сразу во всех местах плохая или хорошая. Но первое, что в глаза бросается - какой он тяжёлый.
Я, в силу опыта работы с ним, хорошо знаю недостатки Битрикса. Но при этом на Вордпресс я не согласен. У него своих проблем вагон. В частности мне показалось довольно сложным поддерживать вордпресс в свежем состоянии. Потому что при обновлениях он склонен разваливаться. А если не поддерживать, то он тут же становится целью для атак. Битрикс в этом плане намного лучше. У него надёжно работающие обновления, и есть кое-какие инструменты контроля безопасности.
Не могу ничего сказать про другие CMS в сравнении - не имею опыта. Зачем вообще выбирать Битрикс? Мне кажется, Битрикс, он такой энтерпрайзный. Как 1C, винда, всякие ERP-системы. Ты платишь за лицензию, тебе дают сапорт (неплохой, кстати), обновления, а вокруг куча компаний, которые готовы разрабатывать и поддерживать сайты на Битриксе. На Битриксе работает куча корпоративных сайтов, которые не интернет-магазины.
Ну и конечно, часто решение о том, что использовать принимает разработчик, на которого довелось наткнуться заказчику. Я лично сделал горстку мелких сайтов на младших версиях Битрикса. Почему не другая CMS? Потому что я работал с Битриксом. Почему не голый фреймфорк? Потому что небольшой сайт со стандартным функционалом проще сделать на CMS.
Уже давно нет. Тарифы "для битрикса" есть, но это, так сказать, legacy маркетологов. Знаю много сайтов на битриксе, которые работают на самых простых тарифах хостинга по 199 рублей, если у сайта не какая то экстраординарная посещаемость и пряморукие разработчики, которые потратили немного времени и прикинули какие объекты насколько нужно кэшировать, проблем никаких.
Странный размен, лара на это. (не фанат, давно почти без php, но справедливости ради..)
К сожалению, немного опыта с ним чудом я получил (на минималках, два проекта, прошу не пинать).
Перед применением полезно читать - https://habr.com/en/post/282333/, но это не точно.
Сочная ссылка:) Спасибо.
Насчёт размена... Ну не размен, конечно же. Нет. Я просто иногда учу что-то новенькое, просто так. Чаще всего - для себя, сама покупаю курсы в свободном ритме. Сейчас я решила сделать наоборот - вписалась на стажировку в крупной компании. Работала я в основном раньше тоже в свободном ритме - типа полставки, где я единственный программист (а всего людей десять), или где я - одна/вдвоём на бекенде, а есть ещё, скажем, фронтенд и девопс. Или ещё мобильные и фронтенд. И тоже девопс. Короче, очень был ограниченный опыт по взаимодействиям. Причём когда разработчиков пятеро, и все разные, это уже процессы выраженные, но никто ещё о них не подумал. И даже не думает думать. Особенно начальник, которому кажется, что от людей ему нужен код, поэтому надо им повторить пять раз, что уже нужен код.
Короче, это сейчас для меня ещё и опыт с тикетами (впервые), с соглашениями по именованию веток в гите (и тоже впервые), ну и др.
И я даже успела трижды обговорить с начальством, можно ли спрыгнуть на ларавель обратно. У них всё там же.
Но. Битрикс - это магия. Вот. Я осознала.
Тут просто нужен бубен.
А если серьёзно, это феноменальная школа, мне кажется. Я же до этого пробовала поучить Yii, и оскорбилась, что там шаблоны с вкраплениями php. Смешно вспоминать.
Битрикс, конечно же, ужасен с точки зрения разработчика по всем возможным параметрам, и этому всегда противопоставляется, как бы, его успешность как продукта.
Однако, Битрикс как CMS для веб-сайта ужасен и с точки зрения продукта!
Изначальный смысл любой CMS - это разделить функции разработчиков и пользователей которые управляют контентом. Разработчики добавили фичи, натянули дизайн, выдали логины/пароли и отдали в эксплуатацию, осталось только посматривать в логи и мониторы, реагировать на технические сбои или атаки.
По факту Битрикс настолько замороченный и сложный в плане интерфейса админки, что сложности с ним испытывают абсолютно все. В качестве контрпримера могу привести другой печально известный своей допотопностью движок WordPress - да, это тоже дырявое PHP, но когда там ставишь там новый модуль или плагин, у него появляется удобная закладочка для управления данными, которую не надо полчаса искать, просматривая все разделы и блоки меню.
ППКС.
Сталкивался с Bitrix несколько раз в качестве специалиста по "заставить это как-то работать" (aka эксплуатация на максималках). Все разы меня терзал странный вопрос: как это чудо света (а это без сомнения чудо света, ибо совершенно не постижимо как при наличии уже понимания, что нужно разделять в сущности представление, действия над ней её данные, всего накопленного опыта CMS можно было породить ЭТО) достигло своих высот.
Для меня как эксплуатации, данная CMS является головной болью. Ей нельзя запретить писать в собственные директории на сервере. То есть, без специальных извращений с несколькими экземплярами PHP под разными пользователями, один из которых под публичную часть, второй под админку, эта штука не способна защитить себя от различных червей. Мне приходилось иметь дело с дырявой Joomla. И манипуляция с правами пользователя PHP на файлы и директории давала достаточно защиты от червей. Да нужно обновляться но сидя в конторе в одно лицо, без умных (ну или просто) семпаев, задача "не ушатай" становится более приоритетной... Такой фокус с Bitrix не прокатит, там нужно иметь 4-й дан в эксплуатации PHP, чтобы защитить это чудо без постоянных обновлений. При чистой эксплуатации, когда все изменения в сайте производит разработка, либо заказчик, а я просто держу это на плаву, единственным решением задачи защиты стало обернуть всё в меркуриал репозитарий, выполнения с некоторой периодичностью status и если там что-то появилось отправку diff на почту, для дальнейшего выяснения, кто-куда-зачем.... Даже, когда разработки утверждала, что оно обновлено, раз в неделю diff давал 100500 файлов загаженных сложно вычленяемыми на фоне остального говнокода сниппетами заразы...
Работа сабжа со стилями вызывает трепет. Если не знать того единственного правильного способа (который мне лично не известен), оно порождает миллион css файлов, и весь этот миллион тянется пользователем при запросе страницы. И эти файлы однотипны и отличаются только штампов времени в конце. Понять откуда это всё без вдумчивого изучения решительно нельзя...
Поменять что-то на странице, если это не предусмотрено разработчиком модуля, вёрстки и прочего, даже при наличии доступа к коду, практически не реально. Понять куда там запрягают коней без специальных курсов решительно нельзя. В админке найти нужно тебе опцию - квест повышенной сложности. Если оно падает, то никто кроме поднимавшего не сможет вернуть всё взад (ну или разворачивание резервной копии с потерей всего, что сделано после её создания). Если человек, кто разворачивал, делал это методом тыка - ничто не поможет кроме бекапа....
Если кто-то сможет объяснить почему оно ТАК популярно, нижайше прошу просветить, иначе у меня создаётся впечатление о клиническом садомазохизме всей отрасли российского сайтоделательства. Нет, как коммерческий продукт, для создателей этой CMS - это просто шедевр: эксплуатация будет платить за лицензию, потому что ей нужны будут обновы. Там есть место облачным сервисам, поскольку НУЖНО регулярное резервное копирование и не помешает CDN, особенно если это чудо развёрнуто на shared-хостинге с драконовскими лимитами по диску. Но блин, что это кроме откатов даёт эксплуатации не ясно. Даже знакомый разработчик сайтов мне не смог внятно ответить о плюсах "продукта", но живописал великим и могучим своё к нему отношение....
А удалось ли вам достаточно изучить его внутренности, чтобы понять, откуда всё-таки записи?
Я, по счастью, даже если на нынешнем месте останусь на Битриксе какое-то время (а может быть, и останусь - это яркий опыт, хотя и нервный), я там точно не буду ответственной за безопасность (потому что будут начальники, над ними начальники и др.)
Но чисто логически. Я вот пытаюсь понять - ну на уровне моей нынешней о нём осведомлённости. Вот есть админка - это единственный блок, который может что-то внутрь писать. А, хотя нет - клиентская часть тоже может. Если мы на странице, и залогинились, мы можем кликнуть "добавить страницу", и клик приведёт к записыванию файла страницы на сервер.
Но всё таки. Все эти записи, вроде бы, это либо стандартные тексты ("добавить на эту страницу код вывода инфоблока между вот этими секциями" - и добавляется код инфоблока, это стандартный текст). Либо ещё стандартные записи в БД.
Вопрос, как туда может что-то ещё просочиться. Через какие действия? Возможно, я бы попробовала логировать время действий. Когда кто в админке кнопку какую нажал. И делала бы дифф каждый раз, после каждого редакторского сеанса... Не уверена, что это хороший способ. Но альтернатива - только выстраивать карту файлов-редакторов. Запись на сервер делают конкретные файлы же.
Ах да, там ещё вопрос в настройке прав в директории на сервере, может быть, у вас сервер слишком открытый наружу? Хотя это, небось, чересчур примитивно - об уровнях доступа наверняка позаботился хостинг.
Эта дрянь должна писать в себя, чтобы жить. Писать она может даже то, что потом она будет исполнять. И МАЛЕЙШЕЕ отверстие, позволяющее выполнить свой (атакующего) код в контексте сервера (а судя по тому, какая круговерть творится вокруг движка, пока он творит свою чёрную магию, этих отверстий там порядком), либо малейшая дрянь которую можно положить через механизмы движка на сервер а затем исполнить php-интерпретатором, даёт полный контроль над всем движком. И червяк начинает методично разбрасывать обфусцированные сниппеты по всем index.php и прочему бардаку, что обильно разбросан по всему движку, на всю, местами неадекватную, глубину вложенности. Я как администратор не могу с этим справится, в Bitrix нет такого каталога, где лежит код, и куда пользователь (лицо взаимодействующее с сайтом даже через админку) писать не должен, и каталога, где лежит переданное от клиента, и от которого должен держаться подальше php-fpm (ну по крайней мере не исполнять от туда скрипты). И это бесит! Я не в силах понять, что творится при создании контента. Простыни инициализируемых объектов мало чем сами отличаются от вредоносов. Ну нет там смысла для взгляда человеческого и нельзя в среднем объять мозгом простынь на 4-10 скролов с перечислением каких-то инициализируемых свойствах убер объекта...
Итого:
Битрикс делает невозможной пассивную защиту, поскольку нельзя реализовать классическую схему W^X (то куда можно записать не должно исполняться)
Он не позволяет легко понять, что на ресурсе происходит что-то не то. Оно штатно разбрасывает неожиданные php файлы в непостижимые места, многие из которых плохо выделяются на фоне вредоносов...
Эта штука умудряется заразиться кажется даже быстрее чем Windows XP с SP1 выставленная голой жопой в интернет. При этом если XP от интернета можно держать на расстоянии, то с Bitrix это не выйдет совсем...
И при всех своих заслугах оно стоит дичайших денег.....
Решительно отказываюсь понимать происходящее.....
Со всем согласен кроме того, что сайт на битриксе умудряется мгновенно заражаться. За свою битриксную карьеру я наблюдал только один случай заражения сайта и то это было сделано через уязвимость шаред-хостинга и с самим битриксом никак связано не было. Чаще всего заражение происходит по вине разработчиков. Через забытые ими инструменты отладки и администрирования, через небезопасные реализации загрузки файлов, через намеренно оставленные бэкдоры.
Возможно это утверждение сделано на основе психологической травмы, нанесённой эксплуатацией этого чуда. Я верю, что знаючи эту тварь дотошно, её можно сделать адекватной (у людей то как-то выходит...). Но всё-таки, если весь контент создаётся путём записи пользовательского ввода в php файлы... это само собой напрашивается на проблемы.... Вот что мешало эти долбаные объекты инициализировать json файлами???...
А так, при общей популярности темы сайтостроительства и общей уверенности, что выучив PHP можно почти сразу разбогатеть на непыльной работе (ну по крайней мере в горизонте прошлых лет), в отрасли полно людей склонных использовать инструменты криво, опасно и даже преступно... Вот только в сочетании с Bitrix это становится просто идеальным штормом...
Но всё-таки, если весь контент создаётся путём записи пользовательского ввода в php файлы...
В норме это доступно только пользователям админки, и сам битрикс позволяет ограничить им права. В проектах, которые разрабатывал я, менеджеры контента имели личные учётки, которым был запрещён доступ к модулю управления структурой, и был разрешён доступ к конкретным инфоблокам. То есть, если это, например, фрилансер-новостник, то он может только писать новости в свой новостной инфоблок, может загружать файлы определённых типов в медиабиблиотеку, и не может править никакие важные файлы сайта. А если в организации всё сурово, и редакция битрикса позволяет, можно это ещё обернуть в бизнес-процессы, чтобы каждую новость утверждал ответственный сотрудник. То есть разделить создание контента и его публикацию.
Классики книг по разработке ПО, уже давно сказали, что если есть возможность купить готовую библиотеку, которая делает то, что нужно, лучше её купить, чем самим разрабатывать. Вот от сюда и причина, почему покупают Битрикс. Там уже есть всё, или почти всё. Разрабатывать на нормальном фреймворке, конечно интересно, но это если нужно сделать немножечко CRUD'ов. А в Битриксе, куча всего уже написано, бери не хочу. Посморите, сколько там модулей и компонентов уже есть, после установки. И всё это добро, стоит не так много, одно-две месячной зарплаты программиста. А пилить столько фич, один программист, будет годами. В этом и секрет популярности "Битры".
Я веб бекендер разработчик с большим опытом. Могу сказать что Битрикс - самая трудная система. Он сложнее: Laravel, Symfony, Python Django, C# .NET, и даже Java Spring. Огромная кодовая база. Под разобраться - я имею ввиду реально знать как работает CIBlockElement::GetList, прям залезть внутрь и разобраться, а не уметь вызывать его с типовыми параметрами.
UPD: а, да, сейчас там же делается через D7, что-то вроде \Bitrix\Iblock\Iblock::wakeUp. Но все равно, сути это не меняет.
Я, в общем, думаю в эту сторону. Вопрос только в том, нет ли ещё какого-то пласта фактов, который надо бы знать помимо кодовой базы. Что-то вроде грамматики. Там материала так много, что очень уже похоже на настоящий язык (типа английский, китайский...) И в данный момент у меня ощущение, что я изучаю слова вообще без каких-либо способов их анализа. Учишься плавать, уже попав в воду - как-то барахтаешься, авось выплывешь. Внутри такой сложной области должны быть какие-то мета-подходы. Для описания, что именно мы изучаем. Паттернами тут пахнет слабо. Но некоторая архитектура есть, это же очевидно. Только вообще не ясно, как она выполнена.
Ну то есть ясно, как в ней копаться: идёшь в файл пролог, дальше во все, кого он там подключает, ну и так далее. Но это же, кажется, в данный момент каждый упоротый должен с нуля картировать. А большинство не упоротых просто тусят снаружи, тыкая в кнопки. Я вообще фигею от метода "сделаем временную страницу, добавим на неё блок этой кнопочкой, потом скачаем код менюшки и вставим в нужное место вёрстки уже целевой страницы. А ещё там что-то из скачанного ещё вон туда положим (далее следует непостижимый по своей структуре путь - куда именно мы переложим созданное на временной страничке)".
Скажем, когда я попробовала (а потом забросила - потому что сравнивала с ларавель, поскольку битрикса ещё не видела) учить Yii, я посмотрела, в частности, видео Павла Климова, "Философия Yii". Стало понятно, зачем они так. Какие там за и против.
Про Битрикс я не понимаю, зачем он такой. Почему он такой. Кто его сделал именно так, из каких соображений. В том же ютубе довольно просто найти (пятьсот) курсов о том, как менюшку добавить, ещё (пятьсот) видео с конференций в духе "как мы боролись с Битриксом на тему ХХ", но нету практически никаких видео о сути событий. Мой пока, кажется, единственный улов - подкаст на "Пятиминутке РНР" (по ссылке в конце статьи). Но там уже только второе ядро - насколько я поняла, они намеренно вообще никак не трогают легаси. Хотя на начальном этапе (как минимум, у меня) дело имеешь именно с этим легаси, и там же.. А, ладно:(
Раньше были интересные курсы от Академия 1С-Битрикс, я смотрел
№1 - Интеграция дизайна и настройка платформы
№2 - Основные технологии и расширение типовых возможностей системы
№3 - Расширенные технологии и производительность
D7. Разработка собственного модуля
Ну то есть ясно, как в ней копаться: идёшь в файл пролог, дальше во все, кого он там подключает, ну и так далее.
В кодовой базе - вам не разобраться. Я бы советовал именно "трясти дерево" как вы говорите. Т.е. вызывать функции с типовыми параметрами, и не рекоммендовал лезть сильно глубоко внутрь. Там очень сложный и непонятный код. Эффективно работать с 1С-Битрикс == хорошо знать как работать с функциями в основном инфоблоков (CIBlockElement::GetList и т.д.), catalog, sale, но != залезть в них внутрь и заковыряться там.
Битрикс состоит из множества слоёв легаси. В некотором смысле они выбрали виндовый подход к развитию. Я работал с битриксом более 10 лет ещё со времён php4, когда никакого ООП там вообще не было. И автолоада тоже. Тогда он не казался мне сложным. Роутинг на файлах был вполне понятен и сваливал всю работу на Apache. Компоненты просто инклюдились и конфигурировались в коде, а визуальный редактор упрощал этот процесс. Потом всё это стало обрастать зачатками MVP в новых компонентах 2.0 и комплексных компонентах, и примитивными зачатками ООП. При этом бешено разрастался функционал ещё на старых технологиях. Компоненты и шаблоны в тыщи строк сохранились в Битриксе до сих пор. Потом борьба за производительность привела к множеству слоёв кеширования. И так далее.
Потом возникла новая надежда - D7. Но он развивался крайне медленно, а старые компоненты никто не спешил переписывать, продукт был уже очень большим. К этому добавился Битрикс Корпоративный портал, который дьявольски оттягивал ресурсы на новые фичи, а рефакторинг так и не наступал. И уж тем более никогда не шло речи о новом Битриксе, несовместимом со старыми наработками. Так что D7 стал лишь ещё одним вариантом сделать что-то в Битриксе.
Из-за того, что компоненты жили в директории bitrix рядом с кодом самого Битрикса, было крайне сложно вести проект в системах управления версиями. Так что добавилась возможность держать свои компоненты и модули в отдельной директории. Что усложнило и без того нелёгкую процедуру поиска кода, который тебе надо исправить. Плюс часть конфигурации всё равно в БД и нет миграций. Запихнул код в гит? Поздравляю, теперь придумай как накатывать данные и обеспечить совместимость с нужной версией Битрикса.
В итоге образовалась какая-то адовая сложность. Тонны документации, курсы, сертификация. Я наблюдал, как люди, которым я делал сайты, даже поддерживать их не могут. Некоторые битриксоиды считают это за плюс - всегда хватает работы по поддержке.
А удалось ли вам картировать, кто кого подключает в старом ядре? Там адское месиво, или это можно до конца довести? Я пару раз начинала, и дважды бросила. Плюс - ещё ни разу не начинала копать админку. А как бы надо бы понимать, как выглядят файлы-редакторы. Т.е., те, которые что-то дописывают/изменяют в вёрстке и в базе данных, когда я кликаю кнопки в админке.
И да, а почему не работает "выгрузить БД тут, импортировать там" - где может выскочить несовместимость с новой версией Битрикса?
А удалось ли вам картировать, кто кого подключает в старом ядре?
Не уверен, что я правильно понял ваш вопрос, но думаю, что я довольно хорошо понимал жизненный цикл страницы. По крайней мере, когда работал с Битриксом. То есть лет, наверное, 7 назад.
И да, а почему не работает "выгрузить БД тут, импортировать там" - где может выскочить несовместимость с новой версией Битрикса?
Так можно. Вообще мне нравились в Битриксе две вещи. Система обновления и система резервного копирования. Первая способна весьма стабильно обновлять систему, причём через множество версий. А вторая способна забэкапить и с помощью одного скрипта развернуть сайт обратно в другом месте.
Но когда работаешь с системой контроля версий, кладёшь туда файлы проекта, ядро битрикса не включаешь. Соответственно появляется зависимость от конкретной версии ядра. В мире пхп такое решается через композер, только не в мире битрикса.
Можно попробовать включить и ядро в проект. Но битрикс ОЧЕНЬ тяжёл, а каждое обновление будет приводить к огромным коммитам.
Чёрт с ним с ядром. Часть конфигурации проекта неизбежно хранится в БД. Инфоблоки, например. Они меняются через интерфейс админки. Как это синхронизировать с кодом? Можно сделать подобие миграций и все подобные изменения реализовывать средствами API. Но тогда мы значительной части функционала админки, за который уплочено. И мы всё ещё не можем гарантировать, что кто-то не сделает в админке что-то, что приведёт к рассинхронизации с зафиксированным состоянием. Плюс обновления битрикса изменяют данные в БД. И как понять, были ли они безопасны относительно того, что зафиксированно в коде или нет?
В корпоративном портале с этим ещё страшнее. Там приходится синхронизировать изменения компонентов, если ты их кастомизировал, чтобы не потерять новые фичи. Так что я перед крупными апдейтами несколько дней на это выделял.
Несколько вопросов сразу.
1) почему бы ядро не хранить отдельным репозиторием. Если их (фирменные) обновления ядра не затрагивают (а хотя как это? Вроде, ядро как раз и обновляют же. Хуже того: без обновлений у вас повышается уязвимость), то вот, ядро в одном месте есть, и пусть будет. А дальше ваш кастомный код вы пушите в другое место. Слить два каталога вместе на одном сервере, вручную, можно всегда.
2) проблема с конфигурациями в БД. Гм. Я-то как раз задавалась вопросом, зачем половина конфигураций в файлах. А видимо, вот поэтому - чтобы хотя бы их можно было переносить легко. Я про разные там "список линков для подключения Asset-ом" или "параметры вызова новостного блока на главной странице (сейчас эта простыня хранится внутри шаблона)". Или ещё набор описаний линков меню (казалось бы, вместо массива $aMenuLinks в файле .bottom.menu.php могли бы быть ровно такое же число строчек в таблице с названием типа b_menu_links_settings).
(тут не очень вопрос получился, скорее, вообще мысли вслух)
3) выше @a0fsпишет страшное. Что там на сервер чего-то вписывается вредоносное. Я пару (новичковых) гипотез в ответ предложила, под его комментарием, но вдруг вы знаете каноническое решение? (подозрительно) или он вообще просто краски сгущает, запугивает. Всё таки чтобы на сервер писалось что-нибудь вне проекта - а как это в принципе может быть? На фоне возможных опций в жизненном цикле страницы админки, которая кнопки слушает и отрабатывает созданием / редактированием кода в файлах внешних страниц?
почему бы ядро не хранить отдельным репозиторием
А кто это должен делать? Я? Но как? Битрикс обновляется через собственную систему обновления.
выше @a0fsпишет страшное. Что там на сервер чего-то вписывается вредоносное.
В принципе, он правильно пишет. Битриксу действительно необходимы права на запись всюду. И даже его собственное ядро не является исключением. Хотя бы из-за обновлений. Но я лично не сталкивался с проблемами из-за этого. Плюс у Битрикса есть собственные механизмы безопасности: проактивная защита, сканер уязвимости. А сам продукт периодически проходит какие-то аудиты безопасности, что даёт какую-то надежду, что при регулярных апдейтах хотя бы через уязвимости ядра ничего не пролезет.
Оценочка под статьёй на данный момент 0 = 8 - 8. Кажется, это очередное высказывание сообщества о самом Битриксе.
И какое оно? Я не могу понять как интерпретировать такие оценки в этом ключе. Статья о том, что вам не понравился Битрикс, значит плюсы статье это минусы Битриксу? А минусы статье, это потому что статья про Битрикс на Хабре не нужна должна быть заминусована. Так что это тоже минусы Битриксу?
Битрикс на Хабре никогда не любили. Самому Битриксу от этого, кажется, ни тепло, ни холодно.
И вовсе статья не об этом. Статья о рац предложениях по упрощениям.
Причём постфактум (уже после этого обсуждения и благодаря ему) я поняла, что я же могу сама кое-что менять. Само собой, не в ядре, но в традициях его использования.
Да, нет такого файла "секьюрити" в исходной сборке. И все (по-дедовски, по-старому) вставляют в каждый файл вёрстки вот это длинное с шайтан-константой, которая должна быть, и быть трушной. И надо каждый раз вспоминать её имя. И эту логику.
Да ради бога - мучайтесь:) А я себе написала файл, вынесла туда вот это вот, и дальше пишу, сама у себя, именно реквайр файл этот. И дальше можно даже похулиганить: не просто вымереть, если что-то не так, а вывести, скажем, "зачем ты ерундой занимаешься?" - как-то раз в книжке прочла такое, мне очень понравилось)
С вызовом компонент так не выйдет, потому что кто-то может потом полезть редактировать через админку, и вынести в отдельные файлы эти вот простыни, или в БД, это не способ. Но я над этим ещё подумаю.
Пока что стало просто в разы проще морально. Что есть свобода на моём уровне писать по-разному.
А я себе написала файл, вынесла туда вот это вот
Кстати, редактор в админке при создании файла использует файл шаблона страницы (их даже может быть несколько на выбор). Можно его отредактировать. В шаблоне сайта это директория page_templates. Документация.
Любопытно, да. Подозреваю, там старая документация, и можно всё то же самое делать внутри папки local (там редактируют внутри папки bitrix). Проверю на свежую голову.
А ещё у меня пока остаётся вопрос, что будет, если включение компонента сделано не напрямую в страницу (в шаблон), а внутрь инклуда, который сам уже встроен в шаблон страницы. Справляется ли с такой двухэтажной конструкцией визуальный редактор.
Вообще говоря... кстати, не должен бы. Ну или надо понять, как он вообще устроен. Думала глянуть сегодня устройство админки, забыла с утра, сейчас вспомнила, заглянула в папочку bitrix/admin (теоретически это то, куда мы идём, чтобы открыть админку). И там правда есть файл index.php. Который, однако, из одной строчки - require '/bitrix/modules/main/interface/desktop.php' от корня сайта.
Собственно, помимо индекса там ещё... добрая сотня файлов, если не несколько сотен. И все, похоже, устроены как "одна строчка: require какой-то модуль от корня сайта". Возможно, там есть и реакции на отдельные действия кнопочек. Но где же это прочесть, не лазия в коде-то, а...
Подозреваю, там старая документация, и можно всё то же самое делать внутри папки local
Можно. Где находится шаблон сайта, там и редактируйте.
А ещё у меня пока остаётся вопрос, что будет, если включение компонента сделано не напрямую в страницу (в шаблон), а внутрь инклуда, который сам уже встроен в шаблон страницы. Справляется ли с такой двухэтажной конструкцией визуальный редактор.
Не совсем. Если просматривать страницу в админке в визуальном редакторе, то там на месте инклюда будет блок "код PHP". Но при просмотре на самом сайте в режиме редактирования Битрикс уже осилит размотать эту цепочку и можно будет в визуальном режиме поправить параметры компонента, который находится в подключаемом файле, а изменения успешно в него запишутся.
Ещё вместо пэхапэшного include() можно использовать компонент включаемой области. Но в данном случае это не очень поможет.
Как то не такой подход к пониманию что ли, написано верстальщикам сложно знать это, то куски php но просто знать include (и лучше делать так то), но если верстальщик дошёл до правки шаблона то он, должен был вызвать компонент и править то место где вызывается. А это по идеи не работа верстальщика совсем. Если говорить про разделение бекенда и фронтенда. Обычно фронтенд делает вёрстку сам как хочет и где хочет, это может быть отдельным разделом чисто с html, может быть в плоть до отдельной репы. А уже бекенд переносит вёрстку, смотрит раздел фронтенда и разбивает то что видит на компоненты, т.е. создаёт шаблон для компонентов или вносит правки бек разработчик, и в его компетенции знать php , и всё это
<?php foreach ($arResult['ITEM'] as $item) : ?>
<?$APPLICATION->IncludeComponent(
<?php if (!defined("B_PROLOG_INCLUDED") || B_PROLOG_INCLUDED !== true) die; ?>
Фронтенду в это и не надо вникать.
Визуальным редавктором лучше не пользоваться, а править файлы в IDE, (вроде бы визуальный редактор может портить файлы) в этом случае вы сами создаёте и редактируете файлы меню, индексы и прочее где хотите и как хотите, а не так называемый “невидимый джинн”. В этом случае всё прозрачно, вы знаете где что создаёте.
Вдруг разработчики Битрикса статью увидят? Они симфонисты
Два вида пыха
Исходный код и визуальный редактор это два вида языка? Чтооооооо?
Что помешало умный редактор сделать слегка иначе: делает вставку: require ...
Нифига себе, вы изобрели включаемые области которые есть в Битрикс с самого начала: https://dev.1c-bitrix.ru/api_help/main/reference/cmain/includefile.php
Альтернатива: в корне лежит файл security.php
Альтернатива: сниппет в IDE и не нужен никакой сомнительный велосипед
С несколько меньшей дальше пойдёт изучать язык. Станет отличным бекендером битрикса, ибо знает поверхность админки уже как свои пять пальцев
Опять же:
Только вопрос: как мне это развидеть? Что помешало сделать таблицы для компонентов, и для конфигов (а это конфиг реально), и вместо вороха строк передавать ID записи в базу?
1 компонент может иметь несколько шаблонов, и кучу мест использования (все это по вашей теории нужно хранить в базе). С таким же успехом предлагайте в Yii2 виджеты хранить в базе.
Плюс в таком варианте кеширование компонента будет работать все равно с базой, вместо того чтобы просто сразу все выплюнуть из кеша.
Ну и собственно такая простыня параметров нужна для того чтобы компоненты были как можно более универсально (чтобы люди могли спокойной в виз редакторе натыкать нужные параметры и не заглядывать в код или кастомизировать шаблон/компонент).
Ну и, опять же, в моём учебном проекте было ещё до меня... 744 таблицы
Это вы еще Битрикс24 не смотрели, где 1.3К таблиц. Правда если спросить "а в чем проблема?" вы вряд ли сможете дать ответ.
Веселят конечно люди, которые засирают Битрикс поработав на нем 1-2 дня/недели, и потом говорят насколько в нем все плохо.
Ах да и пишут на старом коде версии этак 15-ой. С таким же успехом можно говнить Yii2 приводя примеры из Yii1. Если не нравится писать на файлах - пишите контроллеры к роутеру который есть в Битрикс (неожиданно правда, а он оказывается есть);
Судя по вашему описанию "есть карточка с артикулами, а остальное хранится в базе" вы вообще понятия не имеете как устроена архитектура: есть страница (на ней подключается пролог и эпилог), на этой странице указываются компоненты (хоть руками, хоть из виз. редактора), внутри компонента уже есть логика и шаблоны.
Если вы смотрите на задачу с точки зрения верстальщика, то вам нужны только шаблоны - обычные php файлы с версткой, которым компонент скормил данные для отображения (удивительно, но это ой как похоже на View из MVC, но в других фреймворках у вас это вопросы не вызывало, а тут почему-то вызывало).
Да и подключение файлов style.css и script.js к шаблону компонента происходит автоматически, и не обязательно дергать Assets для ручного подключения.
Прежде чем выплескивать кашу из своей головы, я думаю стоит почитать документацию как работать с Битрикс, а не какие-то рандомные статьи из интернета.
Опять же, двойные стандарты: почитать доку к какому то фреймворку - ок, так и нужно делать. А вот для Битрикса - нахер надо, по наитию не пойму - Битрикс говно.
Логика - великолепная :)
Аскеза Bitrix