Дешевый section php. Исповедь битрикс хейтера. Используем Glob() для поиска файлов

Microsoft Office Word предоставляет широкие возможности форматирования таблиц, которые могут представлять собой как самостоятельные документы, так и встроенные в другие текстовые блоки.

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

С помощью функций Word отредактировать размеры можно отдельной ячейки, строки или столбца, таблицы в целом.

Как изменить высоту строки

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

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

Минимальная высота строки не может быть меньше текста в этой строке по вертикали.

Как изменить ширину столбца

В этом случае так же нужен режим «Разметка страницы» для возможности перемещения границы столбца.

Второй вариант – при помощи инструментов на панели, аналогично как для строки. Разница лишь в выборе подбора значения для «Ширины столбца».

Уменьшение ширины столбца возможно до одного символа в ячейке.

Как изменить параметры ячейки

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

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

Как изменить размеры таблицы

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

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

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

Чтобы понимать, что можно ожидать от таблиц при вёрстке, следует знать их явные и неявные особенности, которые перечислены далее.

Вложенные таблицы

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

Размеры таблицы

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

• ширина содержимого ячеек;
• толщина всех границ между ячеек;
• поля вокруг содержимого, устанавливаемые через атрибут cellpadding ;
• расстояние между ячейками, которое определяется значением cellspacing .

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

• Не добавляют в ячейку фиксированной ширины те изображения, размер которых превышает ширину ячейки. Способ, конечно, звучит банально, тем не менее, зная особенности ячеек, можно избежать неприятностей с их отображением.
• Для тега используют стилевое свойство table-layout со значением fixed . Применение этого свойства позволяет обрезать рисунок, если он не помещается целиком в ячейку (пример 2.1).

  Пример 2.1. Использование table-layout

  XHTML 1.0 CSS 2.1 IE Cr Op Sa Fx

  ...

  Результат данного примера зависит от браузера. В старых браузерах рисунок за пределами ячейки обрезается (рис. 2.1а), в современных браузерах рисунок выводится поверх второй ячейки (рис. 2.1б).

  

  б. Вид таблицы в IE8, IE9, Firefox 3, Firefox 4, Safari и Chrome

  Рис. 2.1. Использование table-layout

  Сделать единообразный вид таблицы во всех браузерах легко, для этого к ячейке с рисунком следует добавить свойство overflow со значением hidden . При этом всё, что не помещается в ячейку, будет «обрезано», как продемонстрировано на рис. 2.1а. Стиль в этом случае изменится незначительно.

  TABLE { table-layout: fixed; /* Ячейки фиксированной ширины */ } TD.dino { width: 200px; overflow: hidden; }

  Высота ячеек

  Ячейки в одной строке взаимосвязаны и их высота одинакова. Это позволяет делать макеты с колонками одной высоты. В примере 2.2 приведён такой макет, в котором, несмотря на разную высоту контента, колонки равны по высоте.

  Пример 2.2. Колонки одной высоты

  XHTML 1.0 CSS 2.1 IE 9 Cr Op Sa Fx

  Мясо отварить до готовности. Промыть свеклу, очистить, нарезать соломкой и тушить с помидорами до полуготовности. Бульон процедить, мясо нарезать кусочками. В бульон добавить нарезанный дольками картофель, довести до кипения, опустить нарезанную соломкой свежую капусту и варить 10-15 минут, добавить пассерованные овощи, болгарский перец, нашинкованный тонкой соломкой, специи и довести до готовности. Готовому борщу дать настояться в течение 20-25 минут. При подаче к столу добавить сметану, мясо, зелень.

  Борщ

  Результат примера показан на рис. 2.2.

  

  Рис. 2.2. Макет, созданный с использованием таблицы

  В данном примере в ячейках разное содержание, но высота ячеек одинакова.

  Порядок ячеек

  Основой таблицы выступает строка и ячейка, формирование таблицы происходит слева направо и сверху вниз (рис. 2.3).

  

  Рис. 2.3. Порядок создания ячеек

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

  Загрузка таблицы

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

  Исходя из этого факта, таблицы не используют для хранения большой информации (от 100 Кб). А чтобы ускорить загрузку табличного макета, его разбивают на отдельные таблицы или используют свойство table-layout , применение которого позволяет несколько повысить скорость отображения содержимого таблицы. В обычной таблице браузер анализирует все ячейки и затем уже изменяет ширину колонок на основе этой информации. Включение table-layout со значением fixed меняет алгоритм расчета - браузер анализирует только первую строку и ширину колонок строит согласно ей. За счёт уменьшения числа вычислений и происходит выигрыш скорости отображения таблицы в целом.

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

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

  Случается, что при вставке информации правая часть таблицы Word улетает за видимые пределы листа. В этом случае нужно уменьшить ширину раздвинутого столбца. Это можно сделать при помощи маркера буксировки столбца, если он виден на линейке. Если маркер не виден, то щелчком правой кнопки мыши в этом столбце вызывается окно Свойства таблицы , в котором на вкладке Столбец в поле Ширина указывается некоторый размер в 3-4 см. После этого столбец уменьшится до указанных размеров и его следует более тщательно подровнять.

  

  Если в строках таблицы размещены текстовые данные, то часто строки имеют разную высоту, что портит внешний вид. Чтобы сделать их одинаковыми, следует выделить строки вниз от шапки таблицы (а то она тоже попадет под выравнивание) и на линейке меню выбрать Работа с таблицами – Макет – Выровнять высоту строк.

  

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

  

  При размещении в строках таблицы числовой информации может оказаться, что в заголовках столбцов символов больше, чем в строках. Чтобы не делать из-за этого столбцы широкими, текст в заголовках столбцов можно расположить вертикально (боком). Для этого выделяем ячейки, в которых нужно развернуть текст, и используем кнопку – Направление текста , которая расположена на вкладке Работа с таблицами – Макет – область Выравнивание .

  

  Статья, в которой рассматривается HTML-элемент section из категории sectioning.

  Назначение элемента section

  Элемент section используется для создания секции в документе, которая группирует некоторый тематический контент вместе. Для каждой секции в документе следует указывать её название (тему). Это, как правило, осуществляется с помощью заголовков (элементов h1 - h6).

  Заголовок секции

  Содержимое секции…

  Элементы section , обычно применяются в следующих случаях:

  • для разметки разделов внутри секции. Например, для разметки глав в статье, вкладок в диалоговом окне, разделов в диссертации и т.п.
  • для группировки нескольких секций в одну тематическую группу. Например, для группировки последних новостей на сайте, комментариев к статье и т.п.

  Таким образом, элемент section стоит применять для некоторого контента только в том случае, если он имеет заголовок и является частью чего-то другого.

  Применение элемента section

  Например, рассмотрим фрагмент кода страницы, содержащий статью с комментариями. Каждый из комментариев, оставленных пользователем на странице, содержит некоторый завершенный контент и, следовательно, может рассматриваться как элемент article . Но, в тоже время все комментарии представляют некоторую тематическую группу, и следовательно их можно поместить в элемент section , т.е. данный элемент сгруппирует все эти комментарии на странице вместе.

  Название статьи

  Комментарии

  Заголовок комментария

  Текст комментария...

  Заголовок комментария

  Текст комментария...

  Название статьи Комментарии Заголовок комментария Заголовок комментария

  

  Например, рассмотрим применение элементов section для создания разделов внутри элемента article:

  Название книги

  Первая глава

  Вторая глава

  Третья глава

  Приложение A

  Приложение B

  Вышеприведенный пример будет иметь следующую структуру (outline):

  Название книги Первая глава Вторая глава Третья глава Приложение A Приложение B

  

  Ограничения при использовании элемента section

  Элемент section в HTML 5 не является универсальным элементом для группировки содержимого, т.е. его не следует использовать для оборачивания любого понравившегося контента. Его основное назначение это добавление семантики в документ и создание его структуры (outline).

  Когда автору необходимо сгруппировать контент, только для того, чтобы применить к нему стили или поработать с ним в сценарии JavaScript, ему в этом случае лучше всего будет воспользоваться элементом div . Элемент div в отличие от элемента section , не добавляет семантики в документ и не участвует в создании его структуры (outline).

  Отличие между элементами section и article

  

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

  Но как автору узнать, что собой представляет некоторый контент на странице? Давайте рассмотрим это на примере фрагмента статьи. Фрагмент - это часть статьи и, следовательно, для группировки его контента необходимо применять элемент section . Но этот же фрагмент, уже оставленный в качестве комментария, будет представлять собой нечто целое, завершенное. Следовательно, в этом контексте для его группировки можно использовать элемент article . Но рассуждать, конечно, можно и наоборот. Поэтому, какой элемент использовать для группировки контента, в большинстве случаев зависит от вашего субъективного мнения как автора. Но самое главное в этом подходе поддерживаться выбранной позиции. Поэтому чем автор будет более последовательным в создании структуры, тем он сможет больше смысла в неё вложить.

  Шаблоны в битриксе можно разделить на несколько типов:

  • Шаблоны обычных и комплексных компонентов 2.0
  • Шаблоны сайта
  • Шаблоны прочих сущностей (почтовых отправлений, выпусков рассылок, веб-форм, генераторов экспортов и еще много чего)

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

  В шаблонах компонентов раздражает еще момент с их размещением. Компонент подключается с помощью нехитрой контструкции
  $APPLICATION->IncludeComponent("bitrix:catalog.section", "template_name", );
  В качестве второго параметра идет название шаблона компонента. Так вот в зависимости от различных условий, местоположение этого шаблона может быть в самых неожиданных местах:

  • bitrix/components/bitrix/catalog.section/templates/template_name
  • local/components/bitrix/catalog.section/templates/template_name
  • bitrix/templates/.default/components/bitrix/catalog.section/template_name
  • bitrix/templates/site_template/components/bitrix/catalog.section/template_name
  • local/templates/.default/components/bitrix/catalog.section/template_name
  • local/templates/site_template/components/bitrix/catalog.section/template_name
  • bitrix/components/bitrix/catalog/templates/.default/bitrix/catalog.section/template_name
  • local/templates/site_template/components/bitrix/catalog/.default/bitrix/catalog.section/template_name

  И это еще я не все варианты перечислил…

  Шаблон сайта можно рассматривать как набор файлов: header.php, footer.php (да, у сайта обязательно они должны быть), description.php (системное описание шаблона сайта), template_styles.css (стили шаблона сайта), директорию с шаблонами компонентов и еще группка менее значимых файликов. И все. И никак на это не повлиять, ничего с этим не сделать. Невозможно подцепить шаблонизатор.

  Про другие шаблоны и говорить нечего. Они либо просто хранятся в БД в виде верстки со включением в нее каких-то «переменных» данных, либо это тупой php файл, который делает всю работу, от выборки параметров из БД до вывода информации. Для примера, можно посмотреть на генератор YML файла для маркета. Нет никакого смысла выкладывать его сюда, просто потому, что он достаточно большой, около 2к строк. Кому нужно, тот нагуглит, лежит он в /bitrix/modules/catalog/load/yandex_run.php

  Файловая природа

  Как стало ясно выше, в битриксе с архитектурой все не очень хорошо. Но есть у битрикса и еще один важный аспект архитектуры.
  Битрикс - это на половину файловая CMS. Очень многие вещи управляются с помощью каких-то файлов:

  • Нужна страница - создай файл
  • Нужен набор страниц - создай файл и подключи там компонент, работающий с инфоблоками
  • Нужно задать title для страницы - отредактируй файл
  • Нужно задать title для всех страниц раздела - создай специальный файл.section.php в корне этого раздела
  • Нужно отредактировать права - редактируй файл.access.php
  • Настройки до инициализации системы - в файле dbconn.php, .settings.php и.settings_extra.php
  • result_modifier.php, component_epilog.php, init.php, .parameters.php, .description.php ....

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

  В дополнение к вышесказанному

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

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

  В двух словах попробую охарактеризовать остальные проблемы, с которым приходится сталкиваться ежедневно.

  Админка

  Если кто-то работал с админкой, создавал свои страницы в административной части так, как это предлагает делать битрикс, тот меня поймет. Это просто ад. Для тех, кто не в курсе - битрикс предлагает для каждой страницы использовать файл с лапшой. Например, страница детального просмотра заказа в админке в исполнении разработчиков битрикса занимает over 4к строк. У меня IDE начинает подтормаживать при просмотре содержимого этого файла. Там тебе и php, и js, и html. Хорошо хоть, от SQL избавились, хотя я уверен, что на других административных страницах он есть.
  И что мешало сделать работу административных страниц с помощью тех же компонентов - не понятно. Кастомизировать большинство административных страниц просто нет никакой возможности. В случае с компонентами это можно было бы сделать в два счета.
  К слову, добрые люди сделали модуль , который поможет вам в построении административных страниц

  js-фреймворк

  В битриксе есть js составляющая, которая выполняет роль некоего клиентского фреймворка. Никто из разработчиков не любит его по нескольким причинам:

  • он почти не документирован
  • он монструозен
  • он во многом дублирует привычный многим jquery

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

  Дух копипасты

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

  Asset-management и CDN

  Очень «мне нравится» в битриксе способ управления ресурсами. В принципе, можно зарегистрировать набор определенных «библиотек». Каждая библиотека - это набор css/js файлов, который может зависеть от каких-то других библиотек. Если подключить какую-то библиотеку на страницу, то перед ее подключением будут разрешены все зависимости и все зависимые библиотеки будут вставлены на страницу. Все вроде бы хорошо, только каждый ресурс будет вставлен в виде отдельного файла в тег script или link. И благодаря этому существуют сайты, у которых подключено по 30-50 скриптов и столько же файлов стилей.
  Говно-вопрос, сказали в битриксе, и сделали волшебную галочку, которая объединяет все эти файлы в один. И появились сайты, где вместо 50 скриптов стало 2, каждый по 300-500кб. Какое-то время назад это объединение работало с ошибками и объединяло одни и те же ресурсы по нескольку раз, но сейчас вроде бы исправили.
  И тут битриксоиды выкрутились - прикрутили возможность выгрузить все ресурсы на CDN сервер. Который вечно отваливается…
  Потом появился Google Pagespeed Insights, который рекомендовал опустить все ресурсы в нижнюю часть страницы. И в битриксе опять сделали волшебную галочку, которая тупо опускает все ресурсы в body, если они не помечены специальным атрибутом.
  А еще они вместе с коробкой распространяют минифицированные версии своих скриптов, которые подключаются при использовании еще одной волшебной галочки в админке.
  В общем, никаких вам scss, никаких TypeScript. Хотите грамотно управлять ресурсами - не используйте встроенную систему битрикса, юзайте webpack, который можно спокойно с битриксом подружить.

  Многосайтовость / многоязычность

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

  Механизм управления правами

  Очень замудрили с этой подсистемой. Часто бывает сложно разобраться, почему ты выдал права на просмотр какой-то сущности, а пользователь не может ими воспользоваться. Например, чтобы дать право на редактирование инфоблока, нужно дать доступ к директории /bitrix/admin, выдать права для конкретного инфоблока и выдать права в главном модуле. Чересчур много операций нужно сделать, чтобы выдать права для одной сущности. А если прав не хватает, то без ковыряния в исходниках никак не получится понять - почему.

  Конфигурирование

  В битриксе нет централизованного хаба, который бы позволил управлять настройками системы. Настройки опять таки децентрализованы по всей системе. Опции есть в настройках модуля, в настройках компонентов, в COption (будучи не вынесенными в админку). В админке опции одного модуля могут быть разнесены по 3-4м разным страницам, которые находятся в совершенно разных местах. urlrewrite можно править через админку! Теперь еще и.settings и.settings_extra. Иногда совершенно не ясно, какие из них более приоритетны, очень часто не хватает пояснений для опций, непонятны взаимосвязи. Нет никакого нативного способа расшаривать конфигурацию между разработчиками.
  Настройки бывают очень нелогичными. Иногда доходит до абсурда… посмотрите компонент бигдаты - разве его сможет настроить неподготовленный человек?

  Интеграция с 1С

  Это тот пункт в списке фич битрикса, на который клюет достаточно большое количество заказчиков. Битрикс обещает в 2 клика настроить двустороннюю интеграцию сайта с 1С, которая будет мгновенно доставлять контент и документы от одной системы к другой.
  Да, оно действительно так и есть, но с несколькими оговорками.
  Во-первых, чтобы сделать интеграцию «из коробки» без дополнительных усилий, нужно сделать все именно так, как написано в документации битрикса - построить каталог на сайте по тем правилам, которые предлагает битрикс и построить каталог в 1С, которые требует битрикс. В идеале - создать вообще все с нуля, и тогда может быть, у вас все заработает из коробки.
  Во-вторых, Битрикс дружит не со всеми конфигурациями 1С из коробки. Стоит предварительно ознакомиться
  В-третьих, идеального мира не бывает. Обычно у заказчика, который хочет сайт, уже есть розничный бизнес, а значит уже есть 1С, которая является огромной мусоркой. И эту мусорку приходится прокидывать на сайт. А чтобы на сайте не получилось такой же мусорки, требуется значительно доработать механизм обмена.
  Очень часто требования заказчика сильно расходятся с тем видением продукта, которое сформировано у команды Битрикса, и тогда доработка механизма обмена может быть достаточно дорогой, по трудоемкости сопоставимой с разработкой уникального модуля обмена под конкретный случай.
  Поэтому не нужно пытать иллюзий по поводу того, что вам удастся легко интегрировать сайт с 1С. Это все происки маркетологов.

  Доработка обмена с 1С - это тоже отдельная тема. За организацию обмена каталогом отвечает класс \CIBlockCMLImport.- 5.7к строк. Один из главных методов, который чаще всего требует расширения - \CIBlockCMLImport::ImportElement, содержит больше 1к строк. Достаточно раз унаследоваться, пару раз обновить продукт на протяжении длительного времени, и можно получить неработающий обмен с 1С. Поэтому часто разработчики не лезут в этот класс и пытаются как-то влезть в процесс импорта с помощью обработчиков событий. Работать с обработчиками событий в битриксе, особенно в модуле инфоблоков - тоже не очень приятное занятие, хотя бы из-за того, что однотипные события устроены не однородно, а некоторых событий просто не хватает.
  В общем с этим дела обстоят также печально, как и ранее.

  Несогласованность

  Мне порой кажется, что разработчики разных модулей не особенно то общаются между собой. Изучая исходники ядра натыкаешься на очень разнородные решения, которые можно было бы выполнить на одном движке, но они реализованы почему-то по разному.
  Для примера можно взять свойства элементов инфоблоков и UserFields. И та и другая сущность по факту является дополнительным полем для другой сущности. Она имеет тип, имеет значение и описание. Значение хранится в отдельной(ых) таблице(ах) БД, имеют примерно схожий интерфейс доступа к данным. Так почему бы не сделать для них одинаковый интерфейс?
  Вот в конце марта обновился модуль sale до последней версии, и там тоже обещали произвольные свойства для заказов. Неужели там теперь новый, третий интерфейс для работы со расширенными свойствами сущности?

  Битрикс24

  Это вообще отдельная тема для разговора. На почве этой системы часто возникает путаница. Есть 2 варианта исполнения Б24 - SaaS и Standlone. Есть маркетплейс для Б24, но в нем содержатся приложения только для SaaS версии! Если у вас коробочная версия, купленная за 200 кусков, вы не сможете поставить такое популярнейшие приложения, как конструктор документов , да и вообще вы не сможете на свой Битрикс24 поставить ни одно приложение из маркетплейса для Битрикс24. Вот такой парадокс.
  Вместо этого в вашем Битрикс24 будет доступен маркетплейс от обычной версии. Там решений гораздо больше, но они сконцентрированы в основном вокруг Управления Сайтом, а не Б24.

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

  К слову, дорабатывать компоненты в коробочной версии Б24 - та еще задачка. Компоненты, которые генерируют js код, который с помощью ajax обращается к php коду, который в ответ генерирует html+js. Это адовая смесь, в которую очень не хочется погружаться.

  Документация

  Документация по битриксу отстает от развития продукта на 1-1.5 года. Код очень слабо покрыт phpDoc"ами, и часто комментарий перед классом стоит исключительно «для галочки», будучи автоматически сгенерированным в IDE.
  Сам стиль изложения документации в официальных источниках часто бывает слишком «вольным», а содержимое некоторых статей в документации может не иметь никакого отношения к самому битриксу.
  Курс разработчика имеет очень много информации, однако формат, в котором разработчика знакомят с возможностями системы, не дает того уровня восприятия, который требуется. Если вы зайдете в Cookbook Symfony, то там все разложено по полочкам, расписаны все необходимые аспекты в зависимости от версии. Тогда как в битриксе курс обучения разработчика содержит непонятно по какому принципу структурированную информацию по старому и новому ядру, которая подается сначала отдельно, а потом вперемешку, от чего у начинающих возникает головная боль.

  Организация процесса разработки

  Из-за специфичности системы не так уж просто организовать удобный процесс разработки. Не самая свежая версия редакции Бизнес (что была под рукой) после установки занимает, вдумайтесь, почти 530 мегабайт
  $ du -s *|sort -nr|cut -f 2-|while read a;do du -hs $a;done 523M bitrix 204K upload 64K bitrixsetup.php 56K desktop_app 20K readme.html 20K license.html 4,0K web.config 4,0K urlrewrite.php 4,0K readme.php 4,0K license.php 4,0K install.config 4,0K index.php
  Из этого объема добрая половина - это бинарники и установочники, которые в общем-то не нужны для версионного контроля. Вообще говоря, принято не версионировать битриксовое ядро. Разработчики Битрикса как бы сами гарантируют целостность ядра, управляют сами зависимостями версий разных модулей при обновлениях. Но это несет в себе сразу, как минимум, один большой минус - невозможно одной командой из версионного контроля развернуть полностью работающий проект, приходится собирать его по частям: исходники ядра доставать из битриксового бекапа, а исходники разработчиков - из git.
  С базой тоже все не ладно. Если сами вы можете использовать миграции при разработке, то битрикс накатывает обновления в базу с помощью обычных скриптов, которые вы не можете контролировать. Поэтому при обновлениях все равно придется перекидывать бекапы баз от центрального хоста разработки к другим разработчикам.
  Добрые люди, опять же, пилят инструменты , которые помогают это все организовать, но заставить битрикс следовать этим правилам к сожалению до сих пор не удается.
  Официально битрикс разрешает иметь 2 копии одного дистрибутива. Один - для продакшена, второй для разработки. Если у вас несколько разработчиков на одном проекте - то вы, как бы, вне закона) На самом деле, достаточно отрубить машине с битриксом входящие и исходящие подключения с/на www.bitrixsoft.com , и тогда можно наклепать сколь угодно много копий разработки, просто они не смогут самостоятельно обновляться.

  Коллеги

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

  Выводы

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

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

  Жалею ли я о том, что так много времени потратил на работу с этой системой? Скорее да, чем нет. Разумнее было бы потратить это время на изучение чего-то более правильного и более логичного (чем я стараюсь активно заниматься сейчас). Но так уж получилось, что некому было меня направить в правильное русло в начале моего пути.

  Если вы - начинающий php разработчик, то предпочтите Битриксу изучение фреймворков, таких как Symfony, Laravel, Yii, ZendFramework. Поверьте, в будущем это с лихвой окупится. Освоив любой из этих фреймворков вам не составит труда в будущем разрабатывать что-то под Битрикс. Если у вас нет выбора, то изучайте Битрикс, но в свободное время лучше все-таки пытаться погрузиться в мир фреймворков, чтобы поставить мозги на место.

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

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

  UPD. Видно, что статью прочитали сотрудники битрикса. В разделе про Маркетинг я писал, что в разделе Архитектура в курсе разработчика Битрикс написаны маркетинговые призывы. Теперь их там нет. Даже опечатались, видимо, торопились очень.
  
  

  Спасибо nook за наблюдательность и зоркий глаз:)

  Теги:

  Добавить метки