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