WordPress подходит для MVP, когда его существующие возможности сокращают объём собственной разработки. Но контент, бизнес-логика, интерфейс и интеграции не должны смешиваться в один большой файл темы.
1. Разделите слои системы
- WordPress Core: пользователи, публикации, редактор, мультимедиа, права доступа, API.
- Тема: внешний вид, шаблоны и адаптивная подача данных; при смене темы контент не должен исчезнуть.
- Собственный companion-плагин: CPT, таксономии, бизнес-правила, обработчики форм, административные экраны и интеграции.
- Сторонние плагины: только функции, которые нужны и поддерживаются; учитывайте обновления и совместимость.
- Внешние API: платёжные, почтовые и AI-провайдеры с отдельной моделью ошибок и ограничений.
Документация WordPress рекомендует регистрировать CPT именно в плагине, а не в теме, чтобы структура контента не зависела от оформления.
2. Спроектируйте модель данных
Для каждой сущности решите: нужна ли ей отдельная страница и жизненный цикл (post_type), классификация (taxonomy), параметр одного объекта (post_meta) или отдельная таблица из-за объёма и характера запросов.
Например, «Проекты» могут быть CPT, «Тип проекта» — таксономией, а «Цена по договору» — защищённым метаполем. Персональные документы и платёжные события не стоит делать публичными постами только потому, что в WordPress есть CPT.
3. Опишите границы интеграций и права
Для каждого REST endpoint укажите метод, назначение, схему входа/выхода, permission_callback, обработку ошибок, rate limit при необходимости и кто владеет данными. Nonce не заменяет проверку авторизации и capabilities.
Критичные токены не храните в HTML-шаблонах или публичных JS-файлах. Не публикуйте реальные API-ключи в промптах и репозитории.
4. Сформулируйте критерии качества
Минимум: бэкап до миграции, логирование ошибок без секретов, отдельный staging, восстановление доступа администратора, реальные мобильные проверки, тесты ролей, обработка конфликтов URL и правильная индексация.
При подготовке разработки через AI-агента полезно заранее дать ему правила структуры данных, но ссылку добавляйте в публикацию только при наличии материала.
Шаблон 07-PRODUCT-SPEC.md
## PRODUCT-SPEC
- Цель MVP:
- Пользователь / основной сценарий:
- Технологический стек и ограничения:
## Компоненты
- WordPress Core:
- Тема (отвечает за):
- Собственный плагин (отвечает за):
- Сторонние зависимости:
- Внешние API / вебхуки:
## Сущности
- CPT / taxonomy / meta / отдельная таблица:
- Публичные и приватные данные:
- Владелец и жизненный цикл:
## URL и SEO
- Индексируемые типы:
- Архивы / canonical / redirects:
## Безопасность
- Роли и capabilities:
- Авторизация REST:
- Секреты и PII:
## Надёжность
- Резервная копия / откат:
- Логи / мониторинг:
- Тестовая среда:
## Acceptance
1. Основной сценарий работает без разработчика
2. Ошибочные данные не меняют публикацию
3. Недостаточные права блокируют операцию
4. URL и SEO не дублируютсяКак принимать архитектуру
Проведите разбор двух изменений: что будет при смене темы и что произойдёт при замене одного внешнего сервиса. Если изменение оформления ломает данные или API не имеет сценария отказа, архитектуру стоит упростить до начала разработки.
Источник: https://developer.wordpress.org/plugins/post-types/registering-custom-post-types/
Материал был полезен?
Помогите нам сделать материалы точнее и понятнее.