content-management-systems

Этот скилл GitHub посвящён разработке и изменению систем управления контентом и программ, которые ведут себя как CMS. Его область охватывает WordPress, Shopify, Wix, Squarespace, Drupal, WooCommerce, Joomla, HubSpot CMS Hub, Webflow, Adobe Experience Manager и похожие платформы. В центре внимания находятся темы и шаблоны, плагины, приложения, модули и другие точки расширения, интерфейсы администратора и редактора, загрузка медиа, модели контента, таксономия, метаданные, Markdown-пайплайны и статический экспорт. Это не готовая интеграция с одной конкретной CMS, а рабочая схема, которая помогает сначала определить платформенный контекст, а затем найти место, где действительно должна жить правка. Первый проход начинается с классификации системы: self-hosted CMS, SaaS-конструктор сайта, commerce-платформа или гибридная/headless-система. После этого скилл предлагает найти владеющий слой: тему или шаблон, плагин, приложение, модуль или extension point, административную поверхность, модель или хранилище контента, медиапайплайн либо экспорт, деплой и рендеринг. До выбора реализации нужно проверить ограничения платформы: что редактируется локально, что является авторским контентом, а что кодом, где должны лежать медиа и будет ли итоговый сайт серверным, статически экспортированным или размещённым удалённо. Такой порядок уменьшает риск исправить downstream-include, когда источник поведения находится выше, или записать важные данные в презентационную разметку. Для тем и шаблонов скилл рекомендует начинать с загрузчика шаблонов или runtime темы, сохранять иерархию шаблонов и соглашения имён partial-файлов, а изменения представления держать рядом с шаблонами и общими помощниками темы. Для плагинов, приложений и модулей предпочтительна штатная точка расширения, а не рассеивание логики по шаблонам; миграции, seed-данные и конфигурация должны быть явными и версионируемыми. В админке формы должны соответствовать хранимой модели контента, нетривиальные преобразования полезно показывать автору через preview, а валидацию, CSRF или эквивалентные меры и права доступа следует согласовать с окружающим кодом. Медиа разделяются по назначению: авторские файлы получают выделенный upload-путь, изображения темы остаются в активной теме, а для обычных случаев предложены conventional locations вроде uploads/ для авторского контента и img/ для ресурсов темы, если сама платформа не задаёт более сильное правило. Для моделей контента важно различать страницы, записи, товары, entries, collections, таксономии и настройки; слаги, даты публикации, excerpts, canonical metadata и связи таксономий лучше хранить структурированно. Перед изменением Markdown-рендера нужно определить, является ли Markdown входом автора, промежуточным представлением или результатом сборки, и по возможности связать изменение с preview или проверкой. В статическом экспорте отдельно проверяются переписанные permalink и пути к assets после сборки. Скилл полезен как карта точек ответственности и последовательность проверки; конкретные API, миграции и ограничения выбранной CMS всё равно нужно подтвердить её документацией.