У одного автора решения на Маркетплейсе, может быть множество модулей.
Часто бывает необходимо, разработать модуль, который в себя будет включать другие модули автора (а еще лучше, чтобы можно было подключать бесплатные модули других авторов).
таким образом, необходимо, чтобы для любого решения на маркетелейсе, можно было бы указать зависимости (зависимые модули) и необходимые версии.
А при установке модуля с зависимостями, будут устанавливаться также и зависимые модули.
Часто бывает необходимо, разработать модуль, который в себя будет включать другие модули автора (а еще лучше, чтобы можно было подключать бесплатные модули других авторов).
таким образом, необходимо, чтобы для любого решения на маркетелейсе, можно было бы указать зависимости (зависимые модули) и необходимые версии.
А при установке модуля с зависимостями, будут устанавливаться также и зависимые модули.
День добрый!
Просьба добавить в списке установленных решений доп.колонку - дата установки
Иногда бывает надо понять, как давно установили модуль
Просьба добавить в списке установленных решений доп.колонку - дата установки
Иногда бывает надо понять, как давно установили модуль
Предлагаю в SiteUpdate реализовать поддержку маркировки обновления как важного.
Если обновление отмечено как важное, клиенту при скачивании вываливается попап с чейнджлогом, и установить это обновление становится возможным только после того как клиент поставил галку что ознакомлен с описанием обновления.
Очевидные кейсы использования:
В принципе, это может быть полезно не только для решений из МП, но и для БУС.
Если обновление отмечено как важное, клиенту при скачивании вываливается попап с чейнджлогом, и установить это обновление становится возможным только после того как клиент поставил галку что ознакомлен с описанием обновления.
Очевидные кейсы использования:
- Сложился сценарий, предполагающий существенную перенастройку решения, и по этому сценарию нет возможности корректно сохранить/перенести текущие настройки заданные клиентом. И клиента нужно предупредить о том, что сразу после обновления до этой версии решения, нужно произвести те или иные действия.
- В решение введены зависимости, например, отказ от поддержки версии PHP ниже 7.0 или наличие какой либо библиотеки. Ведь автор МП, в отличие от вендора платформы, не расписывался кровью в том, что будет тянуть древних клиентов ради «полной и обратной совместимости»
В принципе, это может быть полезно не только для решений из МП, но и для БУС.
С тех пор как появился D7 разработчики модулей вздохнули свободнее -- больше в include.php не нужно прописывать все классы модулей. Глядя на исходный код Вашей автозагрузки возник вопрос -- почему бы не разрешить автоматическое подключение модулей? До этого остался ровно 1 шаг -- если модуль не подключен, проверять его в папках bitrix/modules/ и local/modules/
А для модулей, чьи авторы все-таки хотят сохранить строгость в подключении, можно предусмотреть опцию -- можно или нет подключать модуль автоматически по мере надобности
А для модулей, чьи авторы все-таки хотят сохранить строгость в подключении, можно предусмотреть опцию -- можно или нет подключать модуль автоматически по мере надобности
Привет всем.
Не понимаю почему забыли сделать вкладку доступ в модуле поиска:?:
Она очень нужна, чтобы дать контент-менеджеру доступ к статистике поиска тут:
Настройки > Поиск > Статистика > Список фраз
Статистика поисковых фраз
Не понимаю почему забыли сделать вкладку доступ в модуле поиска:?:
Она очень нужна, чтобы дать контент-менеджеру доступ к статистике поиска тут:
Настройки > Поиск > Статистика > Список фраз
Статистика поисковых фраз
Сделайте модули модулями — целостной подсистемой, после подключения которой не нужно раскидывать по всему сайту файлы с компонентами, картинками, шаблонами и пр. Модуль, с точки зрения разработчика, должен быть прост в установке и обновлении.
Структура модуля могла бы быть такой:
Итого:
Структура модуля могла бы быть такой:
vendor.module/ admin/ lib/ components/ templates/ |
- разработчику модуля не нужно при выпуске очередного обновления, например, компонентов, писать апдейтер, который будет копировать файлы из модуля в bitrix/components/vendor;
- все ресурсы модуля находятся в модуле.
Страница админки "Управление модулями" не самая популярная - о ней вспоминают пару раз за проект (в начале или в конце удаляют все лишние модули, время от времени переустанавливают вновь понадобившиеся). Но это не повод делать ее неудобной. В чем неудобство, спросите Вы?
На современных широких мониторах это выглядит вот так (). Название модуля - слева, а статус (установлен/удален) и кнопки справа. Во время массовой установки/удаления это вызывает невероятный дискомфорт - нельзя одним взглядом охватить сразу и названия модулей и их статусы. Приходится сжимать окно браузера до смешных размеров (), но куда лучше было бы изменить макет этой страницы. Прошу задуматься об изменении структуры этой страницы. Что в первую очередь волнует пользователей здесь? Название модуля, его статус и кнопка (почему бы их не объединить?). Потом уже описание, версия, дата обновления.
На современных широких мониторах это выглядит вот так (). Название модуля - слева, а статус (установлен/удален) и кнопки справа. Во время массовой установки/удаления это вызывает невероятный дискомфорт - нельзя одним взглядом охватить сразу и названия модулей и их статусы. Приходится сжимать окно браузера до смешных размеров (), но куда лучше было бы изменить макет этой страницы. Прошу задуматься об изменении структуры этой страницы. Что в первую очередь волнует пользователей здесь? Название модуля, его статус и кнопка (почему бы их не объединить?). Потом уже описание, версия, дата обновления.
Предлагаю добавить параметр для указания версии ядра битрикса под которой он будет работать.
Зачем?
Поскольку продукт активно развивается и начинает все сильней меняться от релиза к релизу. В данном случае возникают проблемы с совместимостью партнерских модулей с системой.
При установке проверять соответствие. Если ядро меньшей версии, то выводить соответствующее сообщение. Так же добавить данную проверку при установке с маркетплейс.
Сам параметр может выглядеть так:
'core_version' => '>15'
или так
'core_version' => '15.*'
П.С.
Так же можно расширить для проверки версий другий модулей системы (инфоблоки, торговый каталог и т.д.)
Зачем?
Поскольку продукт активно развивается и начинает все сильней меняться от релиза к релизу. В данном случае возникают проблемы с совместимостью партнерских модулей с системой.
При установке проверять соответствие. Если ядро меньшей версии, то выводить соответствующее сообщение. Так же добавить данную проверку при установке с маркетплейс.
Сам параметр может выглядеть так:
'core_version' => '>15'
или так
'core_version' => '15.*'
П.С.
Так же можно расширить для проверки версий другий модулей системы (инфоблоки, торговый каталог и т.д.)
Прошу Вас рассмотреть возможность создания модуля "Каталог товаров 1С-Битрикс" для БУС и Б24, которое позволит переносить (обновлять) все продукты 1С-Битрикс с полным описанием и актуальными ценами.
Это приложение содержит весь перечень товаров 1С-Битрикс с актуальными ценами и описанием. В данном приложении имеется возможность загружать отдельные Категории или весь каталог товаров в каталог БУС или Битрикс24.
По сути, при нажатии "загрузить" создаётся инфо-блок "Каталог 1С-Битрикс" вместе со всем содержимым (св-ва, цены, картинки, описание). У Вас на сайте уже есть такой каталог, т.е. мы будем загружать Ваш актуальный каталог.
Задача приложения поддерживать актуальность цен на Ваши продукты (обновление в ручном или автоматическом варианте). Это всё необходимо потому, что у Вас жесткая ценовая политика и нет возможности ставить свои цены, поэтому, логично, чтобы Вы сами актуализировали данные.
Вы представьте, что у Вас тысячи партнёров и они регулярно заходят к Вам на сайт и смотрят актуальные цены по куче продуктов, а потом они руками у себя на сайте всё исправляют. Бывают и ошибки менеджеров. Чем больше ручных движений, тем больше ошибок!
Это приложение содержит весь перечень товаров 1С-Битрикс с актуальными ценами и описанием. В данном приложении имеется возможность загружать отдельные Категории или весь каталог товаров в каталог БУС или Битрикс24.
По сути, при нажатии "загрузить" создаётся инфо-блок "Каталог 1С-Битрикс" вместе со всем содержимым (св-ва, цены, картинки, описание). У Вас на сайте уже есть такой каталог, т.е. мы будем загружать Ваш актуальный каталог.
Задача приложения поддерживать актуальность цен на Ваши продукты (обновление в ручном или автоматическом варианте). Это всё необходимо потому, что у Вас жесткая ценовая политика и нет возможности ставить свои цены, поэтому, логично, чтобы Вы сами актуализировали данные.
Вы представьте, что у Вас тысячи партнёров и они регулярно заходят к Вам на сайт и смотрят актуальные цены по куче продуктов, а потом они руками у себя на сайте всё исправляют. Бывают и ошибки менеджеров. Чем больше ручных движений, тем больше ошибок!
Разработка ведется на полной версии (на НФР или просто на пустой пока - не важно).
Клиент покупает Стандарт, например.
Прописываю ключ, активирую лицензию и.. начинается!
Модуль такой-то не подохдит - удалить, такой-то - удалить.
Может, сделать что-то более автоматическое?
Вариантов реализации - море.
Сообщать, что модули деактивированы, проверьте лицензию, удалите модули такие-то.
Либо проверить список модулей, удалить не подходящие под лицензию?
И самый простой вариант - выдать СРАЗУ весь список модулей, который необходимо удалить, чтобы соответствовать выбранной лицензии.
А то столько автоматизма, а на лицухах такой 20 век!
Клиент покупает Стандарт, например.
Прописываю ключ, активирую лицензию и.. начинается!
Модуль такой-то не подохдит - удалить, такой-то - удалить.
Может, сделать что-то более автоматическое?
Вариантов реализации - море.
Сообщать, что модули деактивированы, проверьте лицензию, удалите модули такие-то.
Либо проверить список модулей, удалить не подходящие под лицензию?
И самый простой вариант - выдать СРАЗУ весь список модулей, который необходимо удалить, чтобы соответствовать выбранной лицензии.
А то столько автоматизма, а на лицухах такой 20 век!
Новый autoload с поддержкой namespace в модулях зверски удобен. Было бы здорово подружить его и с папкой php_interface, в которой обычно лежит вся кастомная логика сайта.
Чтобы классы, например, вида Bitrix\Local\Tool\Seo искались в /bitrix/php_interface/lib/tool/seo.php и /local/php_interface/lib/tool/seo.php
Тем самым мы превратим php_interface в подобие модуля, который не нужно устанавливать и подключать.
Чтобы классы, например, вида Bitrix\Local\Tool\Seo искались в /bitrix/php_interface/lib/tool/seo.php и /local/php_interface/lib/tool/seo.php
Тем самым мы превратим php_interface в подобие модуля, который не нужно устанавливать и подключать.
Нужна возможность сделать рассылку уведомления всем клиентам, что вышло обновление, исправляющее какой-то критичный баг в модуле.
Это либо простая форма с вводом текста сообщения и кнопкой "отправить".
Либо вот такую галку при загрузке нового решения добавить
При установке этой галки отправляется емейл клиенту о критичном обновлении или в БУС высвечивается панель типа такой
А то вот после обновления Битрикса в моем модуле баг нарисовался и я запарился письма рассылать вручную
Это либо простая форма с вводом текста сообщения и кнопкой "отправить".
Либо вот такую галку при загрузке нового решения добавить
При установке этой галки отправляется емейл клиенту о критичном обновлении или в БУС высвечивается панель типа такой
А то вот после обновления Битрикса в моем модуле баг нарисовался и я запарился письма рассылать вручную
При обновлении и добавлении элементов инфоблоков нужно убрать дополнительные обработки передаваемых значений свойств типа файл (PROPERTY_TYPE=F), если эти свойства являются кастомными (USER_TYPE != "" ).
Например, в файле /bitrix/modules/iblock/admin/iblock_element_edit.php (строка ~568 ) нужно убрать преобразование значения через функцию CIBlock::makeFilePropArray(...).
Это позволит создавать свои загрузчики файлов, которые будут иметь предсказуемую разработчиком логику. Сейчас же с выпуском обновления Битрикса мой модуль перестал работать из-за того, что передаваемый в значение ID файла:
с какого-то фига вдруг превратился в:
Если свойство кастомное то на вход функции ConvertToDB должно поступать ровно то, что отправлено через форму редактирования или через какие-либо средства API.
P.S. В данный момент пришлось переключить свой модуль с использования типа "F" на "N", что накладывает ограничение на использование кастомного свойства в штатных шаблонах решений от Битрикса.
Например, в файле /bitrix/modules/iblock/admin/iblock_element_edit.php (строка ~568 ) нужно убрать преобразование значения через функцию CIBlock::makeFilePropArray(...).
Это позволит создавать свои загрузчики файлов, которые будут иметь предсказуемую разработчиком логику. Сейчас же с выпуском обновления Битрикса мой модуль перестал работать из-за того, что передаваемый в значение ID файла:
array("VALUE"=>777); |
[VALUE] => Array( [name] => [type] => [tmp_name] => [error] => 4 [size] => 0 ) |
P.S. В данный момент пришлось переключить свой модуль с использования типа "F" на "N", что накладывает ограничение на использование кастомного свойства в штатных шаблонах решений от Битрикса.
На официальном сайте 1С-Битрикс уже давно висит заметка о правилах написания исходного кода.
Будем откровенны - следуют им далеко не все программисты. Не раз видел такой сайт-чудище Франкенштейна - сколько программистов - столько и стилей расставления {}, отступов и наименований.
Как же заставить всех следовать правилам? Мои идеи:
1) Ввести в монитор качества тест, который проверял бы оформление всего php-кода в папках local, bitrix/templates, bitrix/php_interface. Хочешь-не хочешь, а люди начнут вспоминать про существование этих правил.
2) В маркетплейсе ввести аналогичную проверку для загружаемых решений. По результату проверки либо совсем запрещать публикацию модуля, либо как-то визуально выделять в маркетплейсе такие решения. Например, если решение прошло проверку на оформление кода, добавлять бейджик "100% следование стандарту" (метод пряника) или наоборот. (метод кнута).
Будем откровенны - следуют им далеко не все программисты. Не раз видел такой сайт-чудище Франкенштейна - сколько программистов - столько и стилей расставления {}, отступов и наименований.
Как же заставить всех следовать правилам? Мои идеи:
1) Ввести в монитор качества тест, который проверял бы оформление всего php-кода в папках local, bitrix/templates, bitrix/php_interface. Хочешь-не хочешь, а люди начнут вспоминать про существование этих правил.
2) В маркетплейсе ввести аналогичную проверку для загружаемых решений. По результату проверки либо совсем запрещать публикацию модуля, либо как-то визуально выделять в маркетплейсе такие решения. Например, если решение прошло проверку на оформление кода, добавлять бейджик "100% следование стандарту" (метод пряника) или наоборот. (метод кнута).
© 2001-2023 «Битрикс», «1С-Битрикс». Работает на 1С-Битрикс: Управление сайтом.
Соглашение об использовании сайта
Соглашение об использовании сайта
