В режиме правки добавлена панель редактирования содержимого страницы. Панель имеет подменю, может быть пришпилена к странице, может быть скрыта (включить обратно можно в настройках интерфейса). Если панель пересекается с панелью компонента, размещенного в самом верху рабочей области (и при этом не пришпилена), то панель страницы не показывается во избежании путаницы. Как и в компонентах, двойной клик по рабочей области открывает редактирование страницы.
В панели инструментов и панелях компонентов появились стильные всплывающие подсказки. Кстати, вернулся функционал индикации доступных обновлений.
Редактирование параметров компонентов, вложенных во включаемую область, теперь доступно в подменю соответствующего компонента.
Мы учли пожелания разработчиков и добавили в меню компонента редактирование файлов шаблона компонента result_modifier.php и component_epilog.php. Теперь можно быстрее добраться до служебных файлов компонента.
В компонент меню (и кнопку "Меню" на панели инструментов) добавлена команда удаления файла меню. Раньше удалить файл меню (иногда создаваемый ошибочно) можно было только в панели управления.
Наконец, мы добавили API для разработчиков, чтобы можно было выделять области редактирования в новом интерфейсе "Эрмитаж" прямо внутри области компонента. Чаще всего, это редактирование элемента списка:
Описание для разработчиков
Как выглядит API редактирования области в компоненте. Пример взят из компонента news.list, код в шаблоне компонента:
<?foreach($arResult["ITEMS"] as $arItem):?> <? $this->AddEditAction($arItem['ID'], $arItem['EDIT_LINK'], CIBlock::GetArrayByID($arItem["IBLOCK_ID"], "ELEMENT_EDIT")); $this->AddDeleteAction($arItem['ID'], $arItem['DELETE_LINK'], CIBlock::GetArrayByID($arItem["IBLOCK_ID"], "ELEMENT_DELETE"), array("CONFIRM" => GetMessage('CT_BNL_ELEMENT_DELETE_CONFIRM'))); ?> <p class="news-item" id="<?=$this->GetEditAreaId($arItem['ID']);?>"> |
В примере добавляются кнопки редактирования и удаления записи. Чтобы действия правильно применялись к нужному элементу списка, в HTML-разметку добавляется идентификатор строки с помощью $this->GetEditAreaId($arItem['ID']). Этот же $arItem['ID'] используется при вызове $this->AddEditAction() и $this->AddDeleteAction(). Параметры методов:
/**** EDIA AREA ICONS ************/ /* inside template.php: $this->AddEditAction( 'USER'.$arUser['ID'], // entry id. prefix like 'USER' needed only in case when template has two or more lists of differrent editable entities $arUser['EDIT_LINK'], // edit link, should be set in a component. will be open in js popup. GetMessage('INTR_ISP_EDIT_USER'), // button caption array( // additional params 'WINDOW' => array("width"=>780, "height"=>500), // popup params 'ICON' => 'bx-context-toolbar-edit-icon' // icon css 'SRC' => '/bitrix/images/myicon.gif' // icon image ) ); icon css is set to "edit" icon by default. button caption too. $this->GetEditAreaId with the same id MUST be used for marking entry contaner or row, like this: <tr id="<?=$this->GetEditAreaId('USER'.$arUser['ID']);?>"> $arParams['CONFIRM'] = false - disable confirm; $arParams['CONFIRM'] = 'Text' - confirm with custom text; no $arParams['CONFIRM'] at all - confirm with default text */ |
В этом обновлении есть и другие изменения, интересные для разработчиков. Теперь при вызове $APPLICATION->SetAdditionalCSS() и $APPLICATION->AddHeadScript() не нужно вручную добавлять к имени файла последовательность ?574385748 (дата изменения файла). При выводе стилей и скриптов дата будет подставлена автоматически (для локальных файлов, конечно). Это же касается стилей шаблона сайта, о чем нас давно просили.
Добавлены новые методы буферизации CBitrixComponentTemplate::SetViewTarget(), CBitrixComponentTemplate::EndViewTarget(), CMain::AddViewContent(), CMain::ShowViewContent(). Об этом я хотел бы поговорить, с вашего позволения, чуть позже.
/bitrix/js/main/core/core_window.js
BX.hint и ниже.
Из PHP библиотека инициализируется так:
imho
В этом релизе - нет, а вообще у нас есть мысли по кастомизации панели, включая отключение тултипов.
Тултипы не пропадают, когда кликаешь по кнопке. Часто они перекрывают выпадающие меню или просто мешают.
Как выглядит API редактирования области в компоненте. Пример взят из компонента news.list, код в шаблоне компонента:
Код
<?foreach($arResult["ITEMS"] as $arItem):?>
<?
$this->AddEditAction($arItem['ID'], $arItem['EDIT_LINK'], CIBlock::GetArrayByID($arItem["IBLOCK_ID"], "ELEMENT_EDIT"));
$this->AddDeleteAction($arItem['ID'], $arItem['DELETE_LINK'], CIBlock::GetArrayByID($arItem["IBLOCK_ID"], "ELEMENT_DELETE"), array("CONFIRM" => GetMessage('CT_BNL_ELEMENT_DELETE_CONFIRM')));
?>
<p class="news-item" id="<?=$this->GetEditAreaId($arItem['ID']);?>">
Где можно посомтреть это в работе?
Просто смотрите такая ситуация : я могу для элемента указать несколько категорий это все заносится в таблицу b_iblock_section_element. Мне нужно было не прибегая к различным граблям выбрать элементы которые есть только в 1 разделе и не выбирать элементы которые есть в 2-х и более разделах сразу
Но я вижу код CIBlockElement::GetList и понимаю что не получится написать у меня фильтр
!SECTION_CODE => 'archive' в catalog.section.top
Т.е. логика выборки в CIBlockElement должна быть ориентирована не на исключение категорий а на исключение Элементов которые присутствуют в этих категориях.
$arItem['EDIT_LINK']
$arItem['DELETE_LINK']
Суть в том, что появляется больше одного шаблона, а для выбора их надо делать дополнительные манипуляции.
Но это так, не критичная фича совершенно, просто подумалось.
О, а на другом сайте позволило..
Еще бы хорошо для включаемых областей такое добавить... а то щас добавить область можно, а удалять - только через "управление структурой".
Мы столкнулись с тем, что объяснять сотрудникам функционал того или иного поля в админке, а особенно в свете ротации кадров, очень утомительно и даже многократные объяснения приводят к тому, что в те или иные поля элемента и не только вносятся совсем не те данные или не так (например если мы ограничили кол-во знаков для сохранения верстки).
аутсорсинг (те же фри контентщики) начинает просто убивать мозг.
А ведь у самой примитивной админки любого бесплатного движка есть замечательная функция таких вот иконок с вопросиком справа у каждого поля, где всплывающая подсказка разъясняет функционал того или иного поля.
Подумав, мы решили этого не делать, потому что путем нажатия на обновление Битрикса все наши труды улетучатся. Это сквозной элемент, который должен быть заложен разработчиками движка.
как-то так.
с ув. Рита.
$this->AddDeleteAction($arItem['ID'], $arItem['DELETE_LINK'], CIBlock::GetArrayByID($arItem["IBLOCK_ID"], "ELEMENT_DELETE"), array("CONFIRM" => GetMessage('CT_BNL_ELEMENT_DELETE_CONFIRM')));
как с этим бороться?
Мне кажется, сайт будет отлично и без всего этого мусора работать... Не подскажете, как его срезать из кода?
В настройках главного модуля (Контроль сессий) появился параметр "Продлевать сессию при активности посетителя в окне браузера", и соответственно добавился в коде блок для обработки этого функционала..
подключает эти файлы, вызывается методом PrologActions класса CAllMain (/bitrix/modules/main/classes/general/main.php)..
там и появился новый "if" в котором проверяется значение параметра "Продлевать сессию при активности посетителя в окне браузера", и если оно TRUE то файлы отдаются клиенту.. но зачем продлевать несуществующую сессию не авторизованного пользователя я так и не понял..
некоторые из этих файлов необходимы для работы медиапроигрывателя и карт например..
Не знаю почему бы их подключение не выполнять непосредственно в шаблоне компонента, которому необходимы эти файлы..
Если в шаблоне news.list вывод элемента обернут в функцию для рекурсивного вызова.
Выходит ошибка Fatal error: Using $this when not in object context in
$this в функции не виден. Замена на $APPLICATION или $component тоже не лечит. Что то надо глобализировать, но что?
Где врем и возможна ли вообще такая конструкция?