Если коротко, то в _this сохраняется объект BXEditor, а затем с помощью методов GetContent() получаем содержимое, а с помощью SetContent и ReInitFrame обновляем содержимое и сам визуальный редактор.
P.S. Event для загрузки скрипта выглядит примерно так:
Вот так еще можно добавить парсер. В пример мы парсим html и заменяем блок с классом "bxhtmled-accordion" на суррогата. Суррогат это визуальное представление кода в редакторе. Но вот как добавить свои обработчики на события вызова контекстного меню, клика и двойного клика.
Если вдруг вы захотите дотянуться до редактора из вне, то он хранится в глобальном windows
var editor = window['BXHtmlEditor'].editors.idLHE_BIZPROC_COMMENT_FORM; //идентификартор формы совпадает с 'idLHE'+FORM_ID передаваемый в копонент main.post.form
editor.SetContent('', true);
editor.ReInitIframe();
Я использую компонент "bitrix:main.post.form" и свою кастомную кнопку. блин, 8 лет прошло, а ничего не поменялось )
Недавно столкнулся с такой проблемой и решил здесь поделиться решением, которое нашел в интернете. Вкратце опишу, где встретилась такая ошибка: на сайте есть модуль парсера, сначала он собирает данные, а затем загружает их в инфоблоки. Так вот малое количество данных успешно загружалось, а вот большое на строке с CIBlockElement::GetList выдавало ошибку "MySQL server has gone away". Не сразу понял в чем дело, но в итоге разобрался - MySQL сбрасывал соединение, т.к. долго не было подключения к базе после подключения к серверу (или как-то так, не силен в терминологии). В общем решение вот такое - в файле "bitrix/php_interface/after_connect.php" нужно добавить строку:
$DB->Query("SET wait_timeout=28800");
Число в скобках - это количество секунд ожидания подключения.
Вот именно. Ваше решение не совсем подходит. По умолчанию в людей включено автокеширование. Т.е. если добавят коммент - счетчик не поменяется. Даже если несколько раз тыкать F5. Или я ошибаюсь? Если нет - то Вам лучше написать реализацию через component_epilog.php. Это было бы очень кстати. У меня как раз сейчас задача: вывести актуальное число комментов к товару. Пока не получается
Нейман Андрей, в том и дело, что она двухстрочная. Если у вас большой текст уже забит, то это крошечное поле вызывает недоумение у редактора. И объяснять, что "надо потянуть за уголок" - всё равно что костыль давать. Просто сам пользуюсь именно этим, ибо было лень custom городить.
Всем хорош модуль "Минимизатор админки v12" - первое, что ставлю на новые сайты, но вот одно "но" - он подключает свои CSS и на публичные страницы, чего по логике быть не должно. К сожалению, судя по всему автор модуля им больше не занимается и обновлений давно не было, поэтому проблему устраним самостоятельно, отредактировав файл \bitrix\modules\imyie.littleadmin\classes\general\main.php
function OnPageStartHandler() {
global $APPLICATION;
if(defined( "ADMIN_SECTION" ) && ADMIN_SECTION === true) {
$APPLICATION->SetAdditionalCSS("/bitrix/themes/.default/imyie.littleadmin.css");
}
}
Вот и все, и модуль полезный сохранили и вес страницы облегчили!
По поводу UPD2...т.е чтобы скрыть путь до файлов нужно такую жуть мутить? Формируем массив путей к архивируемым файлам как у вас в примере (массив $arPackFiles), а далее 2 функции и никаких "созданий копий" не нужно. Найдено тут http://pastebin.com/h8zubtLz.
**Вторая функция сразу отдает сформированный архив на скачивание
Ваш код разумный но подход к решению задачи не понравился. Сама идея того, что нужно создавать копии файлов и временную директорию, только для того, чтобы их скрыть из архива - абсурдна. Снизу ещё один листинг в копилку.
/** * @param $arFiles - массив id файлов bitrix * @param $fileName - название создаваемого архива */ function createZip($arFiles,$fileName){ $zipFileName = "/upload/$fileName.zip";
/*удалить файл если-создан*/ if (file_exists($_SERVER["DOCUMENT_ROOT"].$zipFileName)) { unlink($_SERVER["DOCUMENT_ROOT"].$zipFileName); }
// Массив со списком путей, до архивируемых файлов foreach($arFiles as $iFileID) { $arPackFiles[] = $_SERVER["DOCUMENT_ROOT"].CFile::GetPath($iFileID); }
// Архивирование в zip $zip = new ZipArchive(); //Создаём объект для работы с ZIP-архивами $zip->open($_SERVER['DOCUMENT_ROOT'].$zipFileName, ZIPARCHIVE::CREATE); //Открываем (создаём) архив archive.zip foreach($arPackFiles as $key=> $file){ $zip->addFile($file,basename($file)); //Добавляем в архив файл } $zip->close(); //Завершаем работу с архивом return $zipFileName; }
Стоит помнить, что в head страницы bitrix подключает свои служебные файлы, как минимум эти:
kernel_main.js
kernel_main.css
Что интересно - не авторизованным, простым посетителям эти файлы даром не нужны, но на них уходят 2 GET запроса и примерно 273 кб трафика.
Внимание! Файл kernel_main.css в режиме сжатия и объединения CSS сохраняет там содержимое style.css кастомных шаблонов компонентов, так что будьте внимательны!
еще пара строк для удаления новых горе-задумок: '/<sc ript.+?src=".+?bitrix\/js\/main\/loadext\/loadext[^"]+"><\/sc ript\>/', '/<sc ript.+?src=".+?bitrix\/js\/main\/loadext\/extension[^"]+"><\/sc ript\>/',
Случилось такое, что клиенту было недостаточно поля описания у свойства типа "Файл" с фотографиями - слишком мало текста помещается (ограничение в базе на 255 символов, тип VARCHAR), а работать с изображениями через медиабиблиотеку неудобно. Было принято решение дополнить текстовое поле описания более подробным полем. Вот так:
То есть после нажатия на кнопку "Добавить описание" появляется не одно поле, а два - первое с помощью шаблона пойдет в alt и title к картинке, а второе будет подписью.
Суть решения в работе с событиями OnAfterIBlockElementUpdate, OnBeforeProlog и OnEndBufferContent. Почему не кастомизация страницы редактирования элемента? Оказалось, что список файлов, представленный на картинке генерируется методом модуля fileman - кастомизировать его "легально" не получится - обновления затрут изменения. Таким образом суть решения заключается в добавлении своей таблицы, которая хранит ID значения свойства и подробное описание к этому свойству (картинке). С помощью OnEndBufferContent и регулярных выражений редактируем страницу, добавляя textarea рядом с полем ввода описания. Через событие OnAfterIBlockElementUpdate сохраняем введенные значения в нужной таблице. А в OnBeforeProlog подключаем простой скрипт, который показывает текстовые поля с детальным описанием для тех свойств, где не введено обычное описание (хотя это можно было сделать и в OnEndBufferContent, но так проще и быстрее).
В целом решение простое, но его поиск занимает определенное время, поэтому надеюсь, что кому-нибудь помог. Сам код довольно большой, не вижу смысла выкладывать его целиком. Однако, хочу узнать у сообщества, есть ли смысл сделать такое решения для MarketPlace?
CCheshire, а лезть в ядро - это тоже очень отличный показатель. Если вам нужно лезть в ядро - значит вы не знаете как решить задачу. Битрикс позволяет все сделать в рамках ядра (не модифицируя его), только не все эти способы документированы. Когда только начинал работать, я тоже не парился и делал как проще, но с опытом пришло и знание, что лучше пару лишних часов подумать, чтобы сделать хорошо.
Ни в коем случае не хочу обидеть битриксоидов, поскольку сам такой. Но мы на Битриксе не потому, что это самая удобная система для таки конечного пользователя. Во фронтэнде можно, понятно, вывести так или иначе все, что было введено пользователем. Но иногда нужно, чтобы пользователю было тоже удобно, а не "а чо там - создаем еще пару инфоблоков и один highload-блок..." В данном проекте комп вообще не будет подключен к интернету, поэтому лезть в ядро можно - Битрикс смог бы обновиться только непорочно. По-хорошему, в этом проекте вообще не нужен Битрикс, но во всем остальном проще накидать в нем, за исключением этого старинного недоразумения с одним маленьким полем для описания файла, которого, я согласен, хватает 95% пользователей. Наследоваться от поля "Файл"? А это приведет к возможности ввести пользователю дополнительную инфу там же, где он в элементе добавил картинки? Это опять же "да всего два-три щелчка, и..."
Если мне нужно с помощью браузера найти что-то на странице админки битрикса я жму последовательно F6, Ctrl+F. Таким образом получается избежать вызова битриксового окна поиска:
Поясню, что происходит. Когда нажимаем F6 (справедливо для Chrome, и кажется в Firefox) фокус перескакивает со страницы на адресную строку и соответственно страница уже не может перехватывать нажатия на клавиатуре (заветная комбинация Ctrl+F5), а браузер поиск вызовет все равно в этой же вкладке.
Группы на сайте создаются не только сотрудниками «1С-Битрикс», но и партнерами компании. Поэтому мнения участников групп могут не совпадать с позицией компании «1С-Битрикс».