Идеи пользователя 109495

Многим известен алгоритм кастомизации обмена с 1С.

1. Создать свою страницу в админке
2. Разместить на ней кастомный компонент обмена sale.export.1c
3. Переписать \CSaleExport::ExportOrders2Xml
   

К сожалению, все вызовы в этом классе -- статические и делаются через self:: Например, ExportOrders2Xml вызывает getXmlContragents как self::getXmlContragents. То есть, если даже мы унаследуем класс CSaleExport и переопределим getXmlContragents (не трогая огромный ExportOrders2Xml) то вызываеться будет именно старая версия getXmlContragents.
Собственно идея: чтобы облегчить изменение этого класса все self:: вызовы достаточно заменить на static:: (LSB -- http://php.net/manual/ru/language.oop5.late-static-bindings.php)

С тех пор как появился D7 разработчики модулей вздохнули свободнее -- больше в include.php не нужно прописывать все классы модулей. Глядя на исходный код Вашей автозагрузки возник вопрос -- почему бы не разрешить автоматическое подключение модулей? До этого остался ровно 1 шаг -- если модуль не подключен, проверять его в папках bitrix/modules/ и local/modules/
А для модулей, чьи авторы все-таки хотят сохранить строгость в подключении, можно предусмотреть опцию -- можно или нет подключать модуль автоматически по мере надобности

Предлагаю добавить в БУС настройку "Перенаправлять все исходящие E-mail сообщения на указанные адреса". На время разработки туда вносятся E-mail'ы разработчиков, а в момент сдачи сайта опция отключается и письма начнут уходить настоящим получателям.

Согласитесь, одна из главных проблем разработчика -- как сделать так, чтобы владельцу сайта не уходили тестовые письма. Уже пару раз приходилось программировать подмену получателей писем в событии "onBeforeMailSend". Странно, что такой опции нет в таком большом проекте, как БУС.

Проблема:

Сайт работает с двумя БД: локальной (в ней новости, данные пользователей, прочая обычная информация) и удаленной (внутренняя БД клиента с конфиденциальной информацией, которую недопустимо хранить на сайте).

Работу с внешней БД организовали через подключения d7, но монитор производительности никак не регистрирует такие запросы и не позволяет узнать, есть ли среди них проблемные. А это очень бы не помешало.

Собственно, идея:
Научить монитор производительности в режиме журнала SQL-запросов вести запись SQL-обращений ко всем зарегистрированным подключениям.

Страница админки "Управление модулями" не самая популярная - о ней вспоминают пару раз за проект (в начале или в конце удаляют все лишние модули, время от времени переустанавливают вновь понадобившиеся). Но это не повод делать ее неудобной. В чем неудобство, спросите Вы?

На современных широких мониторах это выглядит вот так (http://shot.qip.ru/00dxgE-116IxPIkQC/). Название модуля - слева, а статус (установлен/удален) и кнопки справа. Во время массовой установки/удаления это вызывает невероятный дискомфорт - нельзя одним взглядом охватить сразу и названия модулей и их статусы. Приходится сжимать окно браузера до смешных размеров (http://shot.qip.ru/00dxgE-116IxPIkQD/), но куда лучше было бы изменить макет этой страницы. Прошу задуматься об изменении структуры этой страницы. Что в первую очередь волнует пользователей здесь? Название модуля, его статус и кнопка (почему бы их не объединить?). Потом уже описание, версия, дата обновления.

Хочется событие OnBeforeSetUserGroup
А то на момент OnAfterSetUserGroup уже никак не узнать, в каких группах пользователь был раньше.

Зачем это нужно

Да вот прямо фрагмент из ТЗ:

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

Почему в визуальном режиме редактирование задач (отображение в виде диаграммы Ганта) не отображаются плановые трудозатраты на задачу? Ведь именно исходя из плановых трудозатрат и даты финиша я и назначаю дату завершения задачи.

Ладно бы эти данные отображались просто по наведению курсора на задачу, но и там этих трудозатрат нету.

При настройке обмена товарами и заказами между ИМ и 1С'кой часто сталкиваемся с проблемами. Решаем их всегда одинаково: при завершении импорта, пока в папке еще лежат XML, копируем их в upload/xml/текущая дата и время/

И тогда пусть 1С сделает хоть 100 выгрузок, у нас останутся на сервере для "расследования" все ее XML'ки
Очень хотелось бы, чтобы такой механизм копирования файлов обмена с 1С был встроен в продукт изначально.

Дано:
Интернет-магазин, обмен товарами, заказами с 1С через XML (стандартно). Создан десяток свойств заказа (типичные свойства - телефон, почта, ФИО, адрес и т.п.)

Проблема:
Очень редко в выгрузке заказов наблюдаются заказы без свойств. Такой проблемный заказ - 1 на 2000 заказов. Расследование показало, что этот XML формируется в ту же секунду, что и оформление заказа.

В ТП Битрикса задан вопрос (тикет 710508 ):
Ответ сотрудника ТП:
Безобразие. В 1С могут улететь заказы без свойств.

Идея:
Защитить транзакциями оформление заказа или добавить некий булевый признак к заказу "годный к выгрузке" и выставлять его только после оформления заказа, прикрепления товаров и всех свойств.

Речь пойдет о методе
https://dev.1c-bitrix.ru/api_help/main/reference/cfile/resizeimageget.php

Метод мощный и удобный. Но недавно столкнулись с интересной проблемой на проекте. Контент-менеджер знал, что баннеры будут урезаны и сразу подготовил картинки нужного размера. При этом картинки весили по 500 кб. В настройках главного модуля стояло сжатие с качеством 95%, но, т.к. картинки были уже нужного размера, сжатия по размеру и качеству не произошло и на главной странице остались картинки по полмегабайта весом.

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

,Стоит добавить параметр FILTER_NAME в news.detail и catalog.element, по аналогии с catalog.section - чтобы можно было задать дополнительные фильтры на детальной странице товара. На данный момент, если нужно скрыть товары из каталога по сложной логике, требуется сделать GetList-фильтр для catalog.section, а в result_modifier, template, component_epilog детальной страницы писать дополнительный запрос/анализировать $arResult элемента. Оба варианта плохи - в первом случае будут дополнительные запросы, а во втором потребуется переписать код GetList-фильтра (дублирование кода)

Пример:
$GLOBALS["arrFIlter"] = array("PROPERTY_HIDDEN" => "Y");

result_modifier.php, template.php

if ($arResult["PROPERTIES"]["HIDDEN"]["VALUE"] == "Y")
{
// Заморочки с организацией 404-ой страницы.
}

Новый autoload с поддержкой namespace в модулях зверски удобен. Было бы здорово подружить его и с папкой php_interface, в которой обычно лежит вся кастомная логика сайта.

Чтобы классы, например, вида Bitrix\Local\Tool\Seo искались в /bitrix/php_interface/lib/tool/seo.php и /local/php_interface/lib/tool/seo.php

Тем самым мы превратим php_interface в подобие модуля, который не нужно устанавливать и подключать.

Компонент профиль пользователя (main.profile) всегда обновляет пользователя целиком. Он каждый раз ожидает, что в $_REQUEST к нему придут EMAIL, LOGIN, NAME и все остальные обычные поля.

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

Предлагаю добавить в компонент настройку - какие именно поля разрешать редактировать, выводить в стандартном шаблоне только их и вытаскивать из $_REQUEST только их.

В компоненте импорта торгового каталога из 1С (catalog.import.1c) есть удачные события: OnBeforeCatalogImport1C и OnSuccessCatalogImport1C.
Очень хотелось бы увидеть аналоги в компоненте импорта справочника (catalog.import.hl).

На официальном сайте 1С-Битрикс уже давно висит заметка о правилах написания исходного кода.
http://dev.1c-bitrix.ru/docs/php_recommendation.php
Будем откровенны - следуют им далеко не все программисты. Не раз видел такой сайт-чудище Франкенштейна - сколько программистов - столько и стилей расставления {}, отступов и наименований.

Как же заставить всех следовать правилам? Мои идеи:
1) Ввести в монитор качества тест, который проверял бы оформление всего php-кода в папках local, bitrix/templates, bitrix/php_interface. Хочешь-не хочешь, а люди начнут вспоминать про существование этих правил.
2) В маркетплейсе ввести аналогичную проверку для загружаемых решений. По результату проверки либо совсем запрещать публикацию модуля, либо как-то визуально выделять в маркетплейсе такие решения. Например, если решение прошло проверку на оформление кода, добавлять бейджик "100% следование стандарту" (метод пряника) или наоборот. (метод кнута).

Коллеги, добрый день!

Есть такая технология - OpenSearch. Если сайт ее поддерживает, то посетителям будет предложено добавить сайт в список поисковых систем браузера и можно будет осуществлять поиск сразу по нужному сайту.

Краткое описание технологии: http://habrahabr.ru/post/65540/

Предлагаю для сайта https://dev.1c-bitrix.ru/api_help/ (документация для разработчиков) сделать такую вещь. Там работы на 5 минут.

http://shot.qip.ru/00dxgE-516IxPIezj/

Обладатели Интернет-Магазинов знают про отличный инструмент "Профили импорта". 1 раз настроили - n раз пользуемся. Очень хотелось бы увидеть такой механизм и на странице резервного копирования. И не нужно слов про регулярное копирование - там профиль только один.

У нас в веб-студии есть определененный стандарт: все обработчики хранятся в модулях в папке lib/eventhandlers/<код модуля, чье событие обрабатывается>.php
Внутри - класс с методами, чьи имена совпадают с названиями событий. Т.е. для события onBeforeUserLogin модуля main обработчик будет такой:
\Intervolga\Diving\EventHandlers\Main :: onBeforeUserLogin

Ситуацию усложняет только необходимость подключения этих обработчиков в include.php файле модуля.

Ничего не напоминает? Когда-то у нас была куча include'ов обычных классов и появился спситель - автозагрузчик D7. Может, сделаете аналогичную автозагрузку обработчиков событий?