Как я создаю плагины для WordPress в Codex для Windows и WSL

Я использую Codex для Windows, Ubuntu в WSL, PuTTY и WinSCP. По этой схеме я сделал два плагина для WordPress. Один из проектов — кино-автопилот: он ищет фильмы по API Кинопоиска и TMDB, добавляет карточки на сайт и подключает публичные плееры по документации их сервисов.

Здесь я расскажу, как организовать такую разработку: подготовить живой локальный сайт, дать Codex доступ к файлам и командам Ubuntu, передать документацию API и постепенно довести плагин до рабочего состояния. Для DLE в конце приведён отдельный пример задания: это рекомендуемый следующий шаг, а не описание уже сделанного мной плагина.

Что получилось: мой кино-автопилот для WordPress

В моём проекте есть групповое добавление фильмов. Вместо ручного заполнения каждой карточки я передаю список в формате «название фильма — год», а плагин постепенно обрабатывает очередь. Список можно подготовить в ChatGPT: например, попросить 200 фильмов без повторов.

Матрица — 1999
Интерстеллар — 2014
Прибытие — 2016

Я передавал GPT-6 Astra документацию API баз фильмов и плееров. Недостающие сведения модель помогала искать. В моей работе она хорошо справлялась с неполными объяснениями, но для повторяемого результата лучше явно описывать требования и проверять, что именно реализовано.

Плагин и тема в моём комплекте называются kino-tmdb.zip и kino-cinema.zip; также я использовал конфигурацию Nginx с кешированием. По моему опыту, комплект работал на WordPress 7.1.3. Это сведения о моей установке, а не подтверждение совместимости со всеми версиями WordPress. Файлы для скачивания на этой странице пока не размещены.

1. Устанавливаем WSL и Ubuntu в Windows

В Windows 10/11 открываем PowerShell от имени администратора и выполняем:

wsl --install -d Ubuntu

Перезагружаем Windows. При первом запуске Ubuntu создаём Linux-пользователя и пароль. Упрощённая установка этой командой рассчитана на Windows 10 версии 2004, сборки 19041 и новее, либо Windows 11; на старых сборках порядок отличается.

Затем Ubuntu можно запускать командой:

wsl.exe -d Ubuntu

Посмотреть установленные дистрибутивы и версию WSL можно из PowerShell:

wsl --list --verbose

Здесь важно различать две команды: wsl --install -d Ubuntu устанавливает среду, а wsl.exe -d Ubuntu запускает уже установленную Ubuntu.

2. Подготавливаем локальный WordPress

В Ubuntu устанавливаем Nginx, PHP-FPM, MariaDB и необходимые PHP-расширения. Для обычной установки из репозиториев Ubuntu отправная точка такая:

sudo apt update
sudo apt install nginx mariadb-server php-fpm php-mysql php-curl php-mbstring php-xml php-zip php-gd php-intl unzip

Этот пример устанавливает PHP из репозитория вашей Ubuntu, а не гарантированно PHP 8.3. До настройки Nginx проверяем установленную версию и сокет:

php -v
ls /run/php/

Далее создаём каталог сайта, отдельную базу и пользователя MariaDB, устанавливаем WordPress и настраиваем виртуальный хост Nginx. В моём примере корень сайта — /home/murkir/localhost, адрес — http://localhost/. Права на каталоги настраиваются под пользователя PHP-FPM; выдавать всему сайту права 777 не нужно.

phpMyAdmin можно установить для удобства работы с базой, но самому WordPress он не требуется. Его нужно отдельно подключить к Nginx и ограничить доступ. Установка пакета без настройки веб-сервера ещё не гарантирует открытие панели.

Конфигурации удобно готовить вместе с ChatGPT, передавая реальные параметры среды. Например:

Настрой локальный WordPress в Ubuntu WSL.
Корень: /home/murkir/localhost
Адрес: http://localhost/
Сначала уточни версию Ubuntu, PHP-FPM, имя сокета и занятость порта 80.
Подготовь конфигурацию Nginx для установленной версии PHP,
команды создания отдельной базы и пользователя MariaDB,
права доступа и проверку запуска служб.
phpMyAdmin нужен только для локального администрирования.
Не используй пароль root базы для WordPress.
Перед перезагрузкой Nginx проверь nginx -t.

Перед разработкой открываем http://localhost/ в браузере Windows: должны работать главная и админка WordPress. Если там открывается другой сайт или ничего не открывается, сначала исправляем адрес, службы и привязку порта. Codex должен разрабатывать плагин на уже работающей установке.

3. Создаём проект в Codex для Windows

В Codex создаём или открываем проект и выбираем папку локального сайта. Из Windows путь к моему WordPress выглядит так:

\\wsl.localhost\Ubuntu\home\murkir\localhost

Можно открыть папку плагинов, как в моём первом запросе:

\\wsl.localhost\Ubuntu\home\murkir\localhost\wp-content\plugins

Для полноценной диагностики удобнее корень сайта: тогда доступны контекст проекта и конфигурация WordPress. При этом разрешённую область изменений нужно явно ограничить каталогом нового плагина и, если требуется, отдельной темой.

В своей работе я выбирал GPT-6 Astra. В вашей установке ориентируйтесь на модели, которые действительно доступны в интерфейсе. Главное для этого процесса — доступ к нужной среде, документации и проверкам.

4. Проверяем, что команды выполняются в WSL

Открытая сетевая папка WSL и выполнение команд в Ubuntu — не одно и то же. Если ваша версия Codex позволяет выбрать среду WSL, выберите нужную Ubuntu. Если команды идут через Windows, укажите выполнять Linux-команды через wsl.exe -d Ubuntu.

До написания плагина дайте такое задание:

Работаем в Codex для Windows с WordPress в Ubuntu WSL.
Все PHP-команды и диагностику сайта выполняй внутри Ubuntu.
Linux-корень сайта: /home/murkir/localhost
Адрес: http://localhost/
Проверь, из какой среды выполняются команды.
Если терминал работает в Windows, запускай команды Ubuntu через wsl.exe.
В Ubuntu проверь pwd, php -v, доступность каталога WordPress
и HTTP-ответ http://localhost/.
Определи реальные пути к журналам Nginx, PHP-FPM и WordPress.
Не публикуй содержимое секретов из wp-config.php.
Если нет доступа к сайту или журналам, сообщи конкретную причину.
Пока не меняй ядро, настройки сервера и существующие плагины.

Пример проверки Ubuntu из PowerShell:

wsl.exe -d Ubuntu -- bash -lc 'cd /home/murkir/localhost && pwd && php -v'
wsl.exe -d Ubuntu -- curl -I http://localhost/

При правильной настройке Codex сможет читать разрешённые файлы, менять код плагина, выполнять PHP-проверки и анализировать доступные журналы. Доступ к журналам зависит от прав пользователя. Просмотр страниц в браузере требует отдельного браузерного инструмента; ответ HTTP 200 не заменяет визуальную проверку.

5. Передаём документацию API

Для кино-плагина нужны сведения не только о поиске фильма, но и об авторизации, полях ответа, идентификаторах, ограничениях и ошибках. Ссылки или файлы документации передаём в проект до реализации интеграции.

• Базы фильмов: поиск по названию и году, получение подробностей, постеры, жанры, страны и идентификаторы.
• Плееры: поддерживаемые ID, формат встраивания, авторизация и разрешённые домены.
• Ограничения: суточная квота, число запросов за период, условия использования данных.
• Примеры: успешный ответ, пустой поиск, неверный ключ и превышенный лимит.

Название «Кинопоиск API» может относиться к разным сервисам. Нужно дать ссылку именно на используемого провайдера. В моей работе встречался лимит 200 запросов в день и недоступность выбранного сервиса из Украины. Это мой опыт с конкретным доступом, а не универсальное условие всех API: актуальную квоту и доступность проверяем в кабинете и документации провайдера.

Ключи вводим в предусмотренных настройках плагина. Секретные серверные токены не должны попадать в публичный JavaScript, логи, Git или распространяемый ZIP. Если для плеера предусмотрен публичный ключ, его используем именно по правилам сервиса.

6. Первый запрос: делаем минимально работающий плагин

Мой первоначальный запрос был коротким: путь к плагинам, адрес живого сайта, ссылка на API и просьба реализовать импорт. Для более управляемого результата его лучше расширить:

Сделай плагин kino-tmdb для WordPress.
Проект: /home/murkir/localhost, Ubuntu в WSL.
Сайт: http://localhost/
Каталог плагина: /home/murkir/localhost/wp-content/plugins/kino-tmdb
Документация API: [вставить ссылки на конкретные сервисы].
Ключи есть; предусмотрите их ввод в настройках, без записи в исходники.
Сначала изучи документацию и установленный WordPress.
Реализуй первый рабочий сценарий:

Администратор вводит название фильма и год.
Плагин ищет совпадения через выбранный API.
При неоднозначном результате предлагает выбрать фильм.
Загружает данные и постер, создаёт запись-черновик.
Сохраняет внешние ID и не создаёт дубль при повторном импорте.
Показывает понятную ошибку при неверном ключе или недоступности API.

Используй штатные механизмы WordPress для HTTP, записей и медиа.
Проверяй права администратора и nonce для изменяющих действий,
валидируй входные данные и экранируй вывод.
Ядро WordPress и чужие плагины не меняй.
Команды выполняй в Ubuntu через WSL.
Проверь активацию и один импорт на живом localhost.
Не утверждай, что импорт проверен, если нет рабочего ключа или сети.

Начинать с одного фильма удобнее, чем сразу отлаживать очередь из двухсот. Сначала проверяем поиск, сопоставление, изображение и защиту от дублей. Затем добавляем фоновые задачи и автоматическую публикацию.

7. Добавляем очередь из списка фильмов

Следующим запросом описываем групповое добавление:

Добавь массовый импорт: одна строка — «название фильма — год».
Сначала покажи разобранный список и ошибки формата.
После запуска обрабатывай очередь небольшими порциями в фоне.
Очередь должна сохраняться между запросами и перезапусками.
Добавь состояния: ожидает, выполняется, готово, нужна проверка, ошибка.
Предусмотри паузу, продолжение и повтор только неудачных заданий.
Не допускай параллельной обработки одного задания и дублей записей.
Учитывай квоты каждого API, таймауты и временные ошибки.
Неоднозначный фильм отправляй на ручной выбор.
Настрой режим публикации: черновик или сразу опубликовано.
Покажи прогресс и журнал без API-ключей.

200 фильмов — не обязательно 200 запросов. На одну строку могут понадобиться поиск и отдельное получение подробностей, дополнительные обращения и повторные попытки. Изображения также загружаются отдельно. При суточном лимите очередь должна останавливаться и продолжаться позже.

Для регулярной обработки без посещений сайта может потребоваться системный планировщик. Обычный WP-Cron зависит от обращений к сайту. Поэтому просим Codex явно объяснить выбранный способ запуска, а при переходе на системный cron — подготовить настройку для конкретного сервера. Паузы между запросами не заменяют контроль квоты.

8. Подключаем плееры и отдельную тему

Интеграцию плееров делаем по документации поставщиков. Наличие TMDB ID не означает, что любой плеер принимает именно его: нужно проверить поддерживаемые идентификаторы и способ сопоставления.

Добавь подключение плееров по переданной документации.
Используй только документированные параметры и поддерживаемые ID.
Не угадывай URL встраивания и не подставляй чужие ключи.
Если совпадения нет, показывай понятное сообщение.
Данные фильма храни в плагине, вывод оформи через согласованный
интерфейс плагина и темы. Смена темы не должна удалять каталог.
Проверь размеры и работу плеера на мобильном.

В моём комплекте для оформления используется тема kino-cinema. Полезно разделять обязанности: плагин управляет импортом, очередью и данными, тема оформляет карточки и страницы. Использование данных, постеров и встраивания должно соответствовать условиям сервисов и правам на материалы.

9. Проверяем до переноса на сервер

Минимальная проверка включает несколько разных случаев:

• Плагин активируется без фатальных ошибок.
• Один фильм находится, постер загружается, карточку можно отредактировать.
• Повторный импорт не создаёт дубль.
• Неверный ключ, пустой ответ и лимит API дают понятное сообщение.
• Очередь продолжает работу после паузы и не запускает один импорт дважды.
• Посетитель без прав не может менять настройки и запускать импорт.
• Плеер и тема работают на компьютере и телефоне.

Для отладки на локальной установке можно включить запись ошибок WordPress без вывода посетителям. Передайте Codex сообщение ошибки и время её появления, чтобы он сопоставил их с журналами. После исправления нужно повторить сценарий, который ломался, а не ограничиваться проверкой синтаксиса.

10. Переносим через WinSCP и проверяем через PuTTY

Локальная Ubuntu и удалённый сервер — разные среды. WinSCP я использую для передачи файлов на сервер, PuTTY — для SSH-команд и диагностики.

1. Сохраняем серверные файлы и базу перед установкой новой версии.
2. Готовим ZIP плагина и темы без ключей, логов и временных файлов.
3. Устанавливаем ZIP через админку WordPress либо передаём файлы WinSCP в соответствующие каталоги.
4. На сервере заново проверяем настройки API, домены плееров, права на загрузки и фоновые задания.
5. Через PuTTY проверяем журналы и запуск планировщика. Если меняли Nginx, сначала выполняем sudo nginx -t, затем перезагружаем конфигурацию.
6. Запускаем один импорт на основном сайте и только потом большую очередь.

Локальный wp-config.php и база разработки не должны случайно заменить рабочие настройки и материалы. Nginx-кеш нужно настраивать отдельно: изменения контента требуют обновления кеша, а админка, авторизованные запросы и служебные обработчики не должны получать чужую закешированную страницу.

Как делать модуль для DLE в Codex

Для DLE я таким способом плагины ещё не делал. Следующий раздел — рекомендуемая схема, которую нужно адаптировать к установленной версии движка. Прямой перенос WordPress-плагина не сработает: отличаются админка, хранение публикаций, дополнительные поля, шаблоны и способы подключения модулей.

Начало то же: отдельный локальный DLE в WSL, работающий адрес в браузере и исходная резервная копия. Затем даём Codex изучить именно эту версию DLE и её документацию, а не просим использовать функции WordPress.

Разработай кино-модуль для установленной локальной версии DLE.
Корень проекта: [реальный Linux-путь].
Адрес сайта: [локальный адрес].
Среда: Ubuntu WSL; команды выполняй внутри неё.
Документация API: [ссылки].
Сначала определи версию DLE и документированные способы расширения.
Предложи расположение файлов и способ установки модуля,
совместимые с этой версией. Не угадывай API движка.
Не редактируй физические файлы ядра вручную.
Если интеграция требует системы плагинов DLE, опиши её операции
и возможность отключения. Если без изменения ядра задача невозможна,
объясни ограничение до реализации.
Первый этап: настройки API, поиск одного фильма, создание черновика,
загрузка постера штатным механизмом DLE, сохранение внешних ID,
проверка прав и защита от дублей.
Второй этап: очередь «название — год», квоты, журнал и возобновление.
Третий этап: вывод данных и плееров в отдельной теме.
Не используй функции, таблицы и хуки WordPress.
Учитывай штатные механизмы доступа, защиты запросов и кеша DLE.
Если нужны свои таблицы, подготовь явную установку и обновление схемы.
Удаление модуля не должно молча удалять добавленные публикации.
Проверь установку на локальном сайте и перечисли результаты.

Выбирать WordPress или DLE лучше по требованиям сайта и поддержке расширения. Мой подтверждённый практический опыт в этой истории — WordPress. Утверждать, что Codex всегда лучше справляется с одним движком, на основании одного проекта нельзя.

Что помогает получить рабочий результат

В моей схеме важнее всего живой сайт в WSL, точные пути и документация конкретных API. Codex получает задачу, меняет код, проверяет доступные сценарии и исправляет ошибки по журналам. Большой плагин удобнее собирать последовательными этапами: один импорт, затем очередь, затем плееры и оформление.

Без ключей нужных сервисов соответствующие интеграции работать не будут. В моём плагине ссылки на получение ключей предусмотрены в настройках. При разработке нового решения это тоже стоит включить в задание: пользователь должен понимать, где зарегистрироваться, какой ключ нужен и как проверить соединение.

Документация

• Microsoft: установка WSL.
• OpenAI: работа приложения в Windows.
• WordPress Plugin Handbook.
• Для DLE — руководство и примеры расширений именно вашей установленной версии.