Идеи пользователя 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". Странно, что такой опции нет в таком большом проекте, как БУС.

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

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

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

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

Коллеги!

Вы внедрили замечательный механизм ORM, благодаря которому создавать свои сущности стало очень просто (с точки зрения программиста). Но раз вы разработали "стандарт" ORM для Битрикса, может, сделаете и набор стандартных компонентов для работы с ним (список записей, страница записи, добавление записи)? В том числе и стандартные страницы для админки со списком записей, фильтром, страницей редактирования записи.

Часто, при установке битрикса на новый хостинг, нужно проверить работоспособность отправки почты. Обычно в командной строке пишут пару строк - if mail echo 'ok' else 'echo 'fail' и так далее. По долгу службы занимаюсь этим часто и очень хотелось бы иметь возможность проверить почту одной кнопкой в админке.

P.S.
Да, в проверке сайта есть отправка почты, но она проверяет только результат функции mail, а хотелось бы иметь возможность воочию убедиться, что почта пришла - чтобы это была форма, типа обратной связи, в которой бы указывался email (по умолчанию - текущего пользователя), а так же тема и тело (с какой-нибудь тестовой рыбой). При отправке формы показывалось бы сообщение, как отработала функция mail, и при этом я мог бы зайти на почту и убедиться, приходят ли письма на самом деле.

Многие любопытные клиенты с шаловливыми ручонками любят залезть в визуальном редакторе в настройки компонентов и что-нибудь там пощелкать. То есть хотелось бы иметь возможность скрывать параметры компонентов. Каким образом? Скажем, в файле .parameters.php шаблона компонента указывать (при программировании сайта), какие настройки оригинального компонента скрывать при редактировании с лица.

То есть, чтобы пользователь мог открыть параметры компонента, но отображались ему не все поля, а только те, которые мы ему оставим. Честно говоря, это полезно было бы и при разработке для программистов - когда компонент имеет несколько десятков параметров, становится сложно ориентироваться. А если бы механизм существовал - можно было бы скрыть те параметры, которые уже не будут меняться.

Пример 1:
на странице каталога размещен комплексный каталог и ID инфоблока не будет меняться никогда с вероятностью 90%, а клиенту это вообще не нужно в 100% случаев - так и нужно дать возможность скрыть эту настройку.
Настройки ЧПУ, кеширования - тоже избыточны для клиента. Оставим ему списки полей, какие где выводятся - и этого будет достаточно.

Пример 2 (VCS):
В проектах с git'ом или любой другой VCS в параметры компонента обычно передаются не ID'шники (которые могут быть различными на dev, stage и prod-серверах), а что-то вроде getIblockIdByCode("news";). Скрыть такое от глаз неподготовленного человека тоже полезно.