Главная › Интернет › Даровой section php. Ограничения при использовании элемента section. Отличие между элементами section и article

Даровой section php. Ограничения при использовании элемента section. Отличие между элементами section и article

Сколько бы мы не использовали PHP, всё равно всплывают некоторые функции, о которых мы даже не слышали. Некоторые из них были бы нам очень полезны. Я создал небольшой список полезных функций, которые должны быть в арсенале каждого PHP программиста.

1. Создание функций с переменным числом аргументов

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

Но для начала, вспомним как мы создаём функции обычным образом:

// функция с двумя необязательными параметрами function foo($arg1 = "", $arg2 = "") { echo "arg1: $arg1\n"; echo "arg2: $arg2\n"; } foo("hello","world"); /* выведет: arg1: hello arg2: world */ foo(); /* выведет: arg1: arg2: */

Теперь посмотрим на то, как можно написать функцию с неограниченным количеством аргументов. Для этого будет использовать метод func_get_args() :

// не указываем аргументы function foo() { // возвращает массив, переданных аргументов $args = func_get_args(); foreach ($args as $k => $v) { echo "arg".($k+1).": $v\n"; } } foo(); /* ничего не выведет */ foo("hello"); /* выведет arg1: hello */ foo("hello", "world", "again"); /* выведет arg1: hello arg2: world arg3: again */

2. Используем Glob() для поиска файлов

Часто названия функций говорят сами за себя. Такого нельзя сказать о функции glob() .

Если не вдаваться в подробности, её функциональность схожа с методом scandir() . Она позволяет найти необходимый файл по шаблону:

// найти все php файлы $files = glob("*.php"); print_r($files); /* выведет: Array ( => phptest.php => pi.php => post_output.php => test.php) */

Для нахождения файлов нескольких типов надо писать так:

// найти все php и txt файлы $files = glob("*.{php,txt}", GLOB_BRACE); print_r($files); /* на выходе: Array ( => phptest.php => pi.php => post_output.php => test.php => log.txt => test.txt) */

Так же можно в шаблоне указать путь:

$files = glob("../images/a*.jpg"); print_r($files); /* на выходе: Array ( => ../images/apple.jpg => ../images/art.jpg) */

Для того чтобы получить полный путь к документу используйте метод realpath() :

$files = glob("../images/a*.jpg"); // Применить функцию "realpath" к каждому элементу массива $files = array_map("realpath",$files); print_r($files); /* выведет: Array ( => C:\wamp\www\images\apple.jpg => C:\wamp\www\images\art.jpg) */

3. Информация об используемой памяти

Если вы будете отслеживать количество памяти, которое съедается на работу ваших скриптов то, наверное, чаще будете их оптимизировать.

В PHP существует мощный инструмент отслеживания используемой памяти. В разных частях скрипта нагрузки могут быть разные. Для того чтобы получить значение используемой памяти в данный момент, нам следует использовать метод memory_get_usage() . Для фиксации максимального количества используемой памяти используем memory_get_peak_usage()

Echo "Initial: ".memory_get_usage()." bytes \n"; /* Initial: 361400 bytes */ // дадим небольшую нагрузку for ($i = 0; $i < 100000; $i++) { $array = md5($i); } // и ещё for ($i = 0; $i < 100000; $i++) { unset($array[$i]); } echo "Final: ".memory_get_usage()." bytes \n"; /* Final: 885912 bytes */ echo "Peak: ".memory_get_peak_usage()." bytes \n"; /* Peak: 13687072 bytes */

4. Информация о процессоре

Для этого необходимо использовать метод getrusage() . Но учтите, что на Windows эта функция работать не будет.

Print_r(getrusage()); /* prints Array ( => 0 => 0 => 2 => 3 => 12692 => 764 => 3864 => 94 => 0 => 1 => 67 => 4 => 0 => 0 => 0 => 6269 => 0) */

Картина, изложенная выше, будет понятно тем, у кого есть опыт в системном администрировании. Для всех остальных предлагаем расшифровку:

ru_oublock: количество операций блочной записи
ru_inblock: количество операций блочного чтения
ru_msgsnd: количество отправленных сообщений
ru_msgrcv: количество принятых сообщений
ru_maxrss: максимальный размер невыгружаемого набора
ru_ixrss: общий объем разделяемой памяти
ru_idrss: общий объем неразделяемых данных
ru_minflt: количество используемых страниц памяти
ru_majflt: количество ошибок отсутствия страниц
ru_nsignals: количество принятых сигналов
ru_nvcsw: количество переключений контекста процессом
ru_nivcsw: количество принудительных переключений контекста
ru_nswap: количество обращений к диску при подкачке страниц
ru_utime.tv_usec: время работы в пользовательском режиме (микросекунды)
ru_utime.tv_sec: время работы в пользовательском режиме (секунды)
ru_stime.tv_usec: время работы в привилегированном режиме (микросекунды)
ru_stime.tv_sec: время работы в привилегированном режиме (секунды)

Для того чтобы узнать какие ресурсы вашего процессора используются скриптом, вам необходимо значение ‘user time’ (время работы в пользовательском режиме) и ’system time’ (время работы в привилегированном режиме). Вы можете получить результат как в секундах, так и в микросекундах. Для того чтобы превратить общее количество секунд в десятичное число, вам необходимо разделить значение микросекунд на 1 миллион и добавить к значению секунд.

Запутанно как-то. Вот пример:

// отдыхаем 3 секунды sleep(3); $data = getrusage(); echo "User time: ". ($data["ru_utime.tv_sec"] + $data["ru_utime.tv_usec"] / 1000000); echo "System time: ". ($data["ru_stime.tv_sec"] + $data["ru_stime.tv_usec"] / 1000000); /* выводит User time: 0.011552 System time: 0 */

Хотя выполнение скрипта заняло около 3-х секунд, процессор не был сильно нагружен. Дело в том, что при вызове (sleep) скрипт практически не потребляет ресурсов процессора. Вообще существует множество задач, которые занимают значительное время, но при этом не используют процессор. К примеру, ожидание операций связанных с диском. Так что вы не всегда используете процессорное время в своих скриптах.

Вот ещё пример:

// пройтись 10 миллионов раз for($i=0;$i<10000000;$i++) { } $data = getrusage(); echo "User time: ". ($data["ru_utime.tv_sec"] + $data["ru_utime.tv_usec"] / 1000000); echo "System time: ". ($data["ru_stime.tv_sec"] + $data["ru_stime.tv_usec"] / 1000000); /* выводит User time: 1.424592 System time: 0.004204 */

Работа скрипта заняла 1.4 секунды процессорного времени. В данном случае, время системных вызовов вообще низкое.

Время работы в привилегированном режиме (System Time) - это время, которое процессор затрачивает на выполнение системных запросов к ядру от имени программы. Пример:

$start = microtime(true); // вызываем microtime каждые 3 секунды while(microtime(true) - $start < 3) { } $data = getrusage(); echo "User time: ". ($data["ru_utime.tv_sec"] + $data["ru_utime.tv_usec"] / 1000000); echo "System time: ". ($data["ru_stime.tv_sec"] + $data["ru_stime.tv_usec"] / 1000000); /* выводит User time: 1.088171 System time: 1.675315 */

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

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

5. Магические константы

В PHP существует множество магических констант, таких как номер текущей строки (__LINE__), путь к файлу (__FILE__), путь к каталогу (__DIR__), имя функции (__FUNCTION__), имя класса (__CLASS__), имя метода (__METHOD__) и пространства имён (__NAMESPACE__).

Все мы их рассматривать не будем. Посмотрим только лишь парочку:

// этот скрипт зависит от текущего расположения файла и // может вызвать проблемы, если его использовать из разных дирректорий require_once("config/database.php"); // этот скрипт не вызовет проблем require_once(dirname(__FILE__) . "/config/database.php");

Используйте __LINE__ при отладке скриптов:

// код // ... my_debug("some debug message", __LINE__); /* выведет Line 4: some debug message */ // ещё код // ... my_debug("another debug message", __LINE__); /* выведет Line 11: another debug message */ function my_debug($msg, $line) { echo "Line $line: $msg\n"; }

6. Генерирование уникальных ID

Бывают такие моменты, когда вам надо сгенерировать уникальную строку. Множество раз я видел, что для решения этой задачи используют функцию md5():

// генерируем случайную строку echo md5(time() . mt_rand(1,1000000));

Но на самом деле для этих целей в PHP есть специальная функция uniqid()

// генерируем случайную строку echo uniqid(); /* выведет 4bd67c947233e */ // ещё разок echo uniqid(); /* выведет 4bd67c9472340 */

Невооружённым взглядом можно заметить, что первые символы мягко говоря схожи… Так происходит из-за того, что данный метод использует время сервера для генерации символов. Это даже полезно, т.к. все сгенерированные значения получаются в алфавитном порядке, что даёт возможность быстро их сортировать.

Для того чтобы уменьшить шансы получения дубликата, мы можем добавить префикс или использовать второй параметр (увеличит количество символов):

// с префиксом echo uniqid("foo_"); /* выведет foo_4bd67d6cd8b8f */ // со вторым параметром echo uniqid("",true); /* выведет 4bd67d6cd8b926.12135106 */ // оба echo uniqid("bar_",true); /* выведет bar_4bd67da367b650.43684647 */

Этот метод генерирует строки размером меньше, чем md5, тем самым вы сможете сэкономить место.

7. Сериализация

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

Вообще говоря, этих методов 2: serialize() и unserialize()

// сложный массив $myvar = array("hello", 42, array(1,"two"), "apple"); // конвертируем в строку $string = serialize($myvar); echo $string; /* выведет a:4:{i:0;s:5:"hello";i:1;i:42;i:2;a:2:{i:0;i:1;i:1;s:3:"two";}i:3;s:5:"apple";} */ // получаем исходное значение $newvar = unserialize($string); print_r($newvar); /* выведет Array ( => hello => 42 => Array ( => 1 => two) => apple) */

Вот так вот работают эти функции. Однако из-за бурного роста популярности JSON, в PHP 5.2 были добавлены 2 метода json_encode() и json_decode(). Их работа схожа с serialize():

// сложные массив $myvar = array("hello", 42, array(1,"two"), "apple"); // конвертируем в строку $string = json_encode($myvar); echo $string; /* выведет ["hello",42,,"apple"] */ // восстанавливаем исходное значение $newvar = json_decode($string); print_r($newvar); /* prints Array ( => hello => 42 => Array ( => 1 => two) => apple) */

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

8. Сжатие строк

Кода мы говорим о сжатии, то на ум сразу же приходят архивные файлы в формате ZIP. PHP предоставляет возможность сжатия длинных строк без всяких файлов.

В следующем примере продемонстрируем работу функций gzcompress() и gzuncompress() :

$string = "Lorem ipsum dolor sit amet, consectetur adipiscing elit. Nunc ut elit id mi ultricies adipiscing. Nulla facilisi. Praesent pulvinar, sapien vel feugiat vestibulum, nulla dui pretium orci, non ultricies elit lacus quis ante. Lorem ipsum dolor sit amet, consectetur adipiscing elit. Aliquam pretium ullamcorper urna quis iaculis. Etiam ac massa sed turpis tempor luctus. Curabitur sed nibh eu elit mollis congue. Praesent ipsum diam, consectetur vitae ornare a, aliquam a nunc. In id magna pellentesque tellus posuere adipiscing. Sed non mi metus, at lacinia augue. Sed magna nisi, ornare in mollis in, mollis sed nunc. Etiam at justo in leo congue mollis. Nullam in neque eget metus hendrerit scelerisque eu non enim. Ut malesuada lacus eu nulla bibendum id euismod urna sodales. "; $compressed = gzcompress($string); echo "Original size: ". strlen($string)."\n"; /* выведет Original size: 800 */ echo "Compressed size: ". strlen($compressed)."\n"; /* выведет Compressed size: 418 */ // возвращаем $original = gzuncompress($compressed);

В наших силах уменьшить объём текста на 50%. В этих же целях можно использовать методы gzencode() и gzdecode(), которые используют другой алгоритм сжатия.

9. Выполнить перед завершением

В PHP существует функция register_shutdown_function() , которая позволит вам выполнить какой-то код перед завершением работы скрипта.

Допустим, вы хотите узнать какую-то информацию… Время работы скрипта:

// получаем время начала $start_time = microtime(true); // какие-то операции // ... // выводим время работы echo "execution took: ". (microtime(true) - $start_time). " seconds.";

На первый взгляд это может показаться тривиальной задачей. Для этих целей, вы можете поместить код в конце файла. Однако если перед этим где-то сработает функция exit(), этот код никогда не сработает. Так же, он не сработает если на странице будет ошибка или пользователь прервёт загрузку страницы (нажав на соответствующую кнопку в своём браузере);

При использовании метода register_shutdown_function() код выполнится в любом случае:

$start_time = microtime(true); register_shutdown_function("my_shutdown"); function my_shutdown() { global $start_time; echo "execution took: ". (microtime(true) - $start_time). " seconds."; }

Вывод

PHP это целая планета, которая не перестаёт нас удивлять своим содержимым. А что думаете вы о данных функциях?

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

Шаблоны обычных и комплексных компонентов 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 за наблюдательность и зоркий глаз:)

Теги:

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

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

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

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

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

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

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

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

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

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

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

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

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

Первая глава

Вторая глава

Третья глава

Приложение A

Приложение B

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

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

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

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

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

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

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

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