Случилось такое, что клиенту было недостаточно поля описания у свойства типа "Файл" с фотографиями - слишком мало текста помещается (ограничение в базе на 255 символов, тип VARCHAR), а работать с изображениями через медиабиблиотеку неудобно. Было принято решение дополнить текстовое поле описания более подробным полем. Вот так:
То есть после нажатия на кнопку "Добавить описание" появляется не одно поле, а два - первое с помощью шаблона пойдет в alt и title к картинке, а второе будет подписью.
Суть решения в работе с событиями OnAfterIBlockElementUpdate, OnBeforeProlog и OnEndBufferContent.
Почему не кастомизация страницы редактирования элемента? Оказалось, что список файлов, представленный на картинке генерируется методом модуля fileman - кастомизировать его "легально" не получится - обновления затрут изменения.
Таким образом суть решения заключается в добавлении своей таблицы, которая хранит ID значения свойства и подробное описание к этому свойству (картинке).
С помощью OnEndBufferContent и регулярных выражений редактируем страницу, добавляя textarea рядом с полем ввода описания.
Через событие OnAfterIBlockElementUpdate сохраняем введенные значения в нужной таблице.
А в OnBeforeProlog подключаем простой скрипт, который показывает текстовые поля с детальным описанием для тех свойств, где не введено обычное описание (хотя это можно было сделать и в OnEndBufferContent, но так проще и быстрее).
В целом решение простое, но его поиск занимает определенное время, поэтому надеюсь, что кому-нибудь помог.
Сам код довольно большой, не вижу смысла выкладывать его целиком. Однако, хочу узнать у сообщества, есть ли смысл сделать такое решения для MarketPlace?
То есть после нажатия на кнопку "Добавить описание" появляется не одно поле, а два - первое с помощью шаблона пойдет в alt и title к картинке, а второе будет подписью.
Суть решения в работе с событиями OnAfterIBlockElementUpdate, OnBeforeProlog и OnEndBufferContent.
Почему не кастомизация страницы редактирования элемента? Оказалось, что список файлов, представленный на картинке генерируется методом модуля fileman - кастомизировать его "легально" не получится - обновления затрут изменения.
Таким образом суть решения заключается в добавлении своей таблицы, которая хранит ID значения свойства и подробное описание к этому свойству (картинке).
С помощью OnEndBufferContent и регулярных выражений редактируем страницу, добавляя textarea рядом с полем ввода описания.
Через событие OnAfterIBlockElementUpdate сохраняем введенные значения в нужной таблице.
А в OnBeforeProlog подключаем простой скрипт, который показывает текстовые поля с детальным описанием для тех свойств, где не введено обычное описание (хотя это можно было сделать и в OnEndBufferContent, но так проще и быстрее).
В целом решение простое, но его поиск занимает определенное время, поэтому надеюсь, что кому-нибудь помог.
Сам код довольно большой, не вижу смысла выкладывать его целиком. Однако, хочу узнать у сообщества, есть ли смысл сделать такое решения для MarketPlace?
Группы на сайте создаются не только сотрудниками «1С-Битрикс», но и партнерами компании. Поэтому мнения участников групп могут не совпадать с позицией компании «1С-Битрикс».
Свойство с картинками - множественное, сколько их будет в элементе заранее неизвестно.
Конечно можно и свойство "строка" сделать множественным, но тогда, при удалении одной из картинок, пришлось бы переписывать значения свойств "Строка".
Но если загружать фото из отдельного инфоблока - это не на много лучше, чем работа с медиабиблиотекой. В моем случае на первом месте было удобство - все на одной странице.
было бы удобно если бы сделали интерфейс привязки такой-же как в элементах СКУ, чтобы на странице товара былы видны все элементы, которые к нему привязаны.
Хотелось бы поинтересоваться, дошла ли эта идея до состояния готового модуля? Сам столкнулся с такой проблемой, только у меня она была несколько масштабнее.
Готовый модуль в таком исполнении был бы слишком простым. Может у вас получится что-то более масштабное?
Еще не так давно в битриксе была переделана загрузка множественного свойства для файлов, там текст описания вводится в другом поле (во всплывающем окне). Так что, вариант про который говорится в посте уже неактуален.
Я бы и в этом году с удовольствием бы увидел эту пару скриптов в init.php и один js файл.
Если говорить про удобство: то можно сделать дополнительную административную страницу, на которой будет множественная загрузка, и доп. страницу удобного для редактирования (либо обойтись страницей списка, в которой можно сразу редактировать несколько строк)
В текущем проекте, зная уровень и возраст заполняющего, будет гораздо проще запретить все апдейты Битрикса и просто потоптаться в файлах ядра - то, о чем автор говорил, как о "нелегальной" кастомизации.
В данном проекте комп вообще не будет подключен к интернету, поэтому лезть в ядро можно - Битрикс смог бы обновиться только непорочно.
По-хорошему, в этом проекте вообще не нужен Битрикс, но во всем остальном проще накидать в нем, за исключением этого старинного недоразумения с одним маленьким полем для описания файла, которого, я согласен, хватает 95% пользователей.
Наследоваться от поля "Файл"? А это приведет к возможности ввести пользователю дополнительную инфу там же, где он в элементе добавил картинки? Это опять же "да всего два-три щелчка, и..."