Форум

Да, если файлов с одинаковым названием много, будут создаваться длинные папки.

Разбивка по папкам появилась не сразу. Если проект работает давно, то возможно наличие старых файлов вне папок.

Я тут потихоньку вспоминаю, как в инфоблоках реализовывалась вставка картинок. Ну представьте, там три способа: 1) картинка с локального компьютера; 2) путь к картинке на сайте; 3) вставка из медиабиблиотеки. И все это должно попадать в одно поле и вести себя совершенно однотипно с точки зрения управления инфоблоком. Единственный способ - всегда делать обособленную копию. Тогда можно не волноваться, что какой-нибудь импорт из CSV сломает всю нашу конструкцию взаимных ссылок.

В элементе инфоблока картинка - это поле типа "картинка" со всеми вытекающими, вроде удаления файла при удалении элемента. Слишком много переделывать, опять же вопрос совместимости возникнет. Документооборот, БП и прочие "прелести".
Если так сильно не хочется иметь дубли картинок, то можно сделать свойство с ID картинки из медиа-библиотеки (и соответствующим интерфейсом выбора) и использовать его при выводе.

Рассмотрим ситуацию. Пусть ставится новость про президента. В библиотеке выбирается фото текущего президента. В новость ставится не копия картинки, а привязка к картинке. [I]Внезапно[/I] избирается другой президент. Контент-менеджер, отвечающий за медиа-библиотеку, либо удаляет неактуальную картинку, либо меняет на новую. Вопрос: что скажут посетители о новости про президента М., в которой стоит фото президента П.? Это не выдуманный пример.

Репортер на самом деле универсальный. Внедряется он примерно так: 1) необходимо описывать сущности; 2) необходимо писать бизнес-логику выборки данных; 3) необходимо делать публичный интерфейс к отчетам.

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

В основе работы репортера лежит принцип ORM. На основе описаний сущностей и связей между ними строится запрос к БД. Сущности могут быть из разных модулей. По нашей практике мы видим, что отчет "на заданную тему" может быть внедрен за пару рабочих дней. API опубликуем в начале следующего года.

Действительно, как посетители могут жить в разных поясах? Непорядок. :)

Либо в настройках ядра стоит автоопределение, либо пользователь сам настроил пояс в своем профиле. Настройка есть и в компоненте профиля, и в компоненте профиля форума.

Мы приняли решение сделать поддержку переводчика Bing. Там тоже нужно ключ получать, но денег (пока) за это не берут.

Мы, конечно, поддержим новую версию переводчика Гугла. Но нужно иметь в виду, что Гугл сделал использование сервиса платным. Не уверен, что все клиенты готовы за это платить.

ALED,
Нужные вам обновления в статусе "бета".
nukemonk,
Мастер переустановит шаблон сайта и вложенные в него шаблоны компонентов. Существующие файлы публичного раздела и данные не будут затронуты.