Мне казалось, что миграция должна была перенести конфигурацию @Richie из компонента в основные настройки, а также включить скрытую настройку сайта show_additional_about_groups. Возможной причиной того, что это не сработало, могло стать изменение имени компонента, так как это легко сделать через интерфейс.
Есть ли причина, по которой миграция полагается только на имя, не проверяя также наличие компонента, у которого remote_url из таблицы remote_themes совпадает? Такой подход позволил бы обнаруживать переименованные компоненты, если они были установлены из официального репозитория.
Скрытая настройка сайта, которая не была включена из-за того, что миграция не произошла, не позволила основному модулю отображать группы, поэтому группы продолжал показывать компонент. Однако глобальное уведомление от компонента сообщало пользователю, что компонент нужно удалить. При этом основной модуль всё равно не показывал группы, так как show_additional_about_groups оставался отключённым, и включить его было непросто.
Таким образом, если автоматическая миграция не сработала, как администраторам выполнить её вручную? Копирование конфигурации не является проблемой. Но когда именно следует переключаться между отображением групп через компонент и через основной модуль, не прибегая к включению скрытой настройки?
Возможно, было бы лучше включить show_additional_about_groups для всех или отобразить эту настройку в интерфейсе до добавления в компонент уведомления о необходимости его удаления. Тогда ручная миграция прошла бы успешно, и основной модуль начал бы показывать группы, так что удаление компонента не оставило бы администраторов без групп на странице «О нас».
Сейчас, когда администратор добавляет группы в настройку сайта «about page extra groups», ничего не происходит, поскольку скрытая настройка show_additional_about_groups не включена. Это кажется ошибкой, хотя с точки зрения разработчика всё работает как задумано. Мне кажется, администраторам было бы проще понять, что происходит, если бы эта настройка была видимой, а не скрытой.
