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

Идея

Модифицировать GetFileArray чтобы он мог получать массивы сразу для нескольких файлов и применить в компоненте news.list, чтобы он не порождал по 2 дополнительных запроса для каждого найденного элемента. Сервер скажет спасибо.

Кому и зачем нужно

В одном из самых популярных компонентов ever является news.list. С давних времен разработчики используют его для вывода всего чего угодно. И в этом важном компоненте нарушается одна из главных заповедей производительности веб-приложений - там запросы в цикле .

Приведу пример.
/bitrix/components/bitrix/news.list/component.php:240
Независимо от настроек всегда получается картинка. И это в цикле:o! Строчкой позже делается аналогичный запрос для детальной картинки. Если у вас в news.list 100 элементов, ждите примерно 100 дополнительных запросов (а то и все 200:!:, если у вас есть и детальная картинка и анонсная).

Кажется, что решение проблемы состоит из 1 действия - выполнить запрос всех картинок разом. Но не тут то было. Метод CFile::GetFileArray не принимает массивы ID, только 1 файл за раз. И это, кстати, большая проблема многих методов Битрикс.

В Битриксе есть замечательный эрмитаж, элементы инфоблока можно редактировать прямо там, где этот элемент выводится. Но форма эта сильно ограничена - нельзя настраивать отображение полей в форме, вкладки, нет ссылки для перехода на настройки инфоблока. Предлагаю добавить ссылочку - редактировать в панели управления.

Часто, при установке битрикса на новый хостинг, нужно проверить работоспособность отправки почты. Обычно в командной строке пишут пару строк - 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";). Скрыть такое от глаз неподготовленного человека тоже полезно.

Часто кастомизация компонента (копирование в свое пространство имен и дальнейшая модификация) делается ради пары-тройки строк кода, которые добавляют в ключ кеша некоторые дополнительные параметры.
Предлагаю избавить нас всех от этих мучений.
Каким образом?
Предлагаю ввести в параметры компонента настройку, назовем ее CACHE_KEYS - множественное поле типа "строка". В ней разработчики будут, так же как в параметре FILTER_NAME, прописывать ИМЯ переменной. В самом компоненте значения будут вытаскиваться из этих переменных и передаваться в метод StartResultCache.
Избежать всеобщей модификации всех компонентов можно, если добавлять параметр CACHE_KEYS автоматически всегда, когда включено кеширование, а перед вызовом компонента добавлять значения в глобальные переменные, откуда и доставать внутри метода StartResultCache.

В админке создать страницу, на которой был бы полный список всех использованных на сайте компонентов с указанием использованных шаблонов.
Зачем это нужно - часто нужно понять, используется ли на сайте какой-то шаблон или кастомный компонент - может, он уже мертвый груз и стоит его удалить?
С точки зрения ничего сложного не вижу - создать табличку БД с колонками для названия компонента, шаблона, пути подключения, а при каждом выполнении функции IncludeComponent добавлять запись в БД, выполняя проверку на уникальность перед добавлением. А в админке отображение этой таблицы + кнопка очистки таблицы.
Чтобы не замедлять сайт, можно вести такую статистку только в режиме отладки сайта.

Очень не хватает возможности просматривать сообщения блога прямо в админке. Особенно это актуально, если используются не сам движок блогов, а только его механизм комментариев.
Сейчас в админке можно увидеть только список самих блогов (в которых размещены сообщения - какие, сколько - непонятно) и комментарии к этим сообщениям.
Просмотр таблицы b_blog_post в админке является довольно слабой заменой.

Хотелось бы, чтобы в админке появилась такая чудесная страница, которая показывала бы отчет по обработчикам событий. Под отчетом я понимаю:
1 Тип события
2 Модуль, к которому относится событие
3 Список обработчиков событий (в том порядке, в котором будут вызываться)
3.1 Название класса и метода/функции-обработчика
3.2 Расположение класса и метода/функции-обработчика (полный путь к файлу, номер строки)
3.3 Признак системности (установлен модулем или разработчиком в init.php)

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

В админке на странице очистки файлов кеша очень не хватает даты последнего сброса кеша.
Хотелось бы примерно так.