По моему мнению, тег Customization > Theme component лучше бы подошел в качестве подкатегории. По крайней мере для меня их проще найти, чем теги, и в последние годы компоненты тем становятся всё более значимыми по сравнению с их аналогами Customization > Plugin (многие из которых переводятся в компоненты тем для удобства использования). Из-за нехватки лучшего термина, они заслуживают… «равного» отношения. В конце концов, они чрезвычайно популярны и являются неотъемлемой частью Discourse на сегодняшний день.
Надеюсь, вы учтете это предложение. Я не носитель английского языка, поэтому извините за неуклюжесть формулировок.
Я думаю, что этот язык может создать путаницу. Раздел «Администрирование» → «Настроить» предназначен только для тем и компонентов тем. В канале Customization > Theme содержится всё, что можно добавить на сайт через этот интерфейс.
У нас уже бывают случаи, когда пользователи помещают темы в свои YML-файлы и пытаются добавить git-репозитории для плагинов через интерфейс. Устранение этого разделения лишь повысит вероятность таких ошибок.
Плагинам, действительно, нужно оставаться в своей отдельной категории, верно?
Разница между компонентом темы и плагином в моей голове уже и так размыта. Я уверен, что любые усилия, направленные на то, чтобы людям было проще понимать, что есть что, пойдут на пользу.
Это немного забавно: долгое время разработчики WordPress спорили о том, куда именно стоит помещать функциональность, и велись дебаты о том, какой код должен находиться в «теме», а какой — в «плагине». Сейчас эти споры кажутся уже почти наивными, ведь всё и вся превратилось в блоки JS, но из-за связи с ядром программного обеспечения нам всё ещё приходится определять, куда именно помещать код: в «плагин» или в «шаблон блока».
У меня никогда не было такого ощущения относительно плагинов в Discourse, в основном потому, что за эти годы люди придумали множество гениальных хаков с использованием компонентов тем. Если бы меня спросили, в чём разница между «плагинами» и «компонентами тем», моей первой мыслью было бы: один устанавливается через поле URL, а другой требует пересборки сайта.
Я определенно готов провести проверку категорий и тегов. В последнее время было несколько хороших предложений по небольшой корректировке структуры, поэтому я соберу всё это воедино и посмотрим, к чему мы придём. Я считаю, что всё, что делает Meta более интуитивно понятной для новых пользователей и тех, кто заходит редко, — это только плюс.
Теперь, когда появился выделенный модератор сообщества, это должно быть менее актуальной проблемой. () Я думаю, что если я буду сортировать и организовывать всё по мере поступления, это покроет большую часть вопросов. У нас также достаточно пользователей с уровнями TL3 и TL4, поэтому, надеюсь, закрепление последовательного шаблона облегчит участие и другим.
Я всё ещё воспринимаю это как изменения во фронтенде против изменений в бэкенде, но обновление до Ember тоже размывает для меня это различие. Похоже, это сделало возможными гораздо больше вещей в темах и темах-компонентах, чем раньше (что отлично, если вы используете хостинг и у вас нет простого доступа для добавления плагина ).
Я считаю, что для не-разработчиков это довольно полезное различие. Красный = /admin/customize, Жёлтый = app.yml. Думаю, этого достаточно, если вы администратор, устанавливающий существующую кастомизацию, а не разработчик, создающий новую.
Спасибо за предложение @Decorbuz Я соберу несколько идей и посмотрим, что мы сможем сделать.
Та же проблема, что и с вопросом, являются ли смартфоны компьютерами или нет. Границы уже не так четкие.
Поэтому каждый форум должен сделать логичный выбор, как организовать вещи: где-то это должно быть по идее или назначению (UX и целевая аудитория имеют значение), или же более важны технические решения (мышление с точки зрения разработки/кода).
Нет правильных или неправильных решений, пока пользователи находят то, что ищут.
Ну, иногда бывают и неправильные решения. Смешивание работоспособных плагинов, тем и компонентов с нерабочими таким образом, что приходится искать правильный тег, — это действительно очень плохая идея
И в целом есть еще одна ошибка, которую администраторы довольно часто допускают, и если я правильно помню, даже документация по тегам Meta или что-то подобное предупреждает об этом: категория не создает контент, а пустые или мало посещаемые категории просто создают путаницу.
Отсутствие ясности не означает, что эти категории обязательно нужно объединять, особенно под именем, предложенным Джастином выше. Мы можем также добавить более подробные объяснения к каждой категории и таким образом устранить часть неоднозначности.
Темы Customization > Plugin требуют пересборки и могут выполняться только пользователями с правами root. Это изменения с более высоким уровнем риска, влияющие на доступность сайта.
Я тоже так думаю. Если требуется какое-либо изменение на бэкенде (код на Ruby), будь то сохранение данных в базе данных или изменение поведения API, скорее всего, вам понадобится плагин.
Если изменение касается только интерфейса, лучше начать с компонента темы и при необходимости перейти к плагину, если ситуация усложнится и потребуются изменения на бэкенде.
Мне нравится эта идея. Она немного сложнее, чем одна категория с разными тегами, но мне нравится более чёткая граница между этими различными элементами настройки.
Тема может касаться только внешнего вида, тогда как для установки плагина требуется доступ к операционной системе машины. Это совершенно разные вещи, и правильные категории позволяют, например, разместить в начале категории тему, которая даст новым пользователям контекст о различиях между ними: как устанавливать, документация по разработке и т. д.
Я уверен, что любые усилия, направленные на то, чтобы людям было проще понимать, что есть что, пойдут на пользу.
Я считаю, что всё, что делает Meta более интуитивно понятной для новых пользователей и тех, кто заходит редко, — это только плюс.
