Как проверить WordPress-плагин, написанный через ChatGPT

Как проверить WordPress-плагин, написанный через ChatGPT

Краткий ответ: WordPress-плагин, написанный через ChatGPT, нужно проверять не только на то, “работает или нет”. Нужно проверить структуру файлов, безопасность, nonce, права пользователей, sanitization, escaping, SQL-запросы, AJAX, REST API, debug.log, PHP-совместимость, нагрузку на базу, работу с WooCommerce, обновление, отключение и удаление плагина.

ChatGPT может быстро создать рабочий черновик плагина, но финальный код нельзя ставить на живой сайт без ревью. Особенно если плагин сохраняет данные, работает с пользователями, формами, файлами, заказами WooCommerce, оплатой, CRM, Telegram, API или админскими настройками.

Если плагин уже установлен и после правок начал ломать сайт, сначала разберите общую проблему по статье что делать, если проект после вайб-кодинга начал ломаться. Если проблема не в одном плагине, а в качестве AI-кода в целом, полезно свериться с разбором почему код от ChatGPT работает, но его сложно поддерживать.

Причина

Плагин WordPress — это не просто PHP-файл. Даже маленький плагин может подключаться к хукам WordPress, создавать шорткоды, добавлять AJAX-обработчики, сохранять настройки в wp_options, создавать таблицы MySQL, выводить HTML, подключать CSS/JS и менять поведение админки.

ChatGPT часто пишет код под конкретный пример из промпта. Если в промпте не было требований по безопасности, совместимости, ролям пользователей, WooCommerce, нагрузке, удалению данных и обновлениям, эти части могут быть пропущены.

Чаще всего проблемы появляются из-за таких причин:

• нет проверки nonce в формах, AJAX и admin actions;
• нет проверки прав через current_user_can();
• данные из $_POST, $_GET, $_REQUEST используются без sanitization;
• вывод HTML идёт без esc_html(), esc_attr(), esc_url() или wp_kses();
• SQL-запросы собраны строками без $wpdb->prepare();
• функции названы слишком общо и конфликтуют с темой или другим плагином;
• весь код лежит в одном файле без структуры;
• плагин работает только у администратора и не проверен на других ролях;
• нет обработки пустых данных, ошибок API и ошибок базы;
• нет uninstall.php или логики очистки данных;
• нет проверки PHP-версии и совместимости с текущим WordPress;
• плагин подключает CSS/JS на всех страницах сайта, даже где они не нужны;
• AJAX или REST API открыты шире, чем нужно;
• нет логов, поэтому причину ошибки сложно найти.

Диагностика

Проверку AI-плагина лучше начинать на staging-копии или локальной копии сайта. Не ставьте непроверенный плагин сразу на рабочий сайт, особенно если там WooCommerce, заявки, личный кабинет или платёжные модули.

Что проверить	Где смотреть	Что считается проблемой
Структура плагина	папка плагина, главный PHP-файл, includes, assets	всё лежит в одном файле, нет разделения логики
Заголовок плагина	главный PHP-файл	нет Plugin Name, Version, Author, Text Domain
Имена функций	все PHP-файлы	save_data(), get_items(), render_table() без уникального префикса
Безопасность форм	HTML формы, обработчик PHP	нет nonce, current_user_can(), sanitization
AJAX	wp_ajax_*, JavaScript, Network	нет check_ajax_referer(), action не совпадает, нет проверки прав
SQL	$wpdb-запросы	нет $wpdb->prepare(), нет лимитов, запросы внутри циклов
Вывод данных	HTML, таблицы, shortcode, admin page	нет esc_html(), esc_attr(), esc_url()
Подключение CSS/JS	wp_enqueue_scripts, admin_enqueue_scripts	скрипты грузятся на всех страницах без необходимости
Ошибки PHP	debug.log, error_log	warning, notice, fatal error после активации
Удаление плагина	uninstall.php, register_uninstall_hook()	данные остаются в базе без контроля или удаляются без предупреждения

Решение

Проверка плагина от ChatGPT должна идти по шагам: сначала безопасность и критические ошибки, потом структура, производительность, совместимость и удобство поддержки.

1. Сделайте backup. Сохраните файлы и базу сайта перед установкой или активацией плагина.
2. Проверьте плагин вне рабочего сайта. Используйте staging, локальную копию или тестовый сайт.
3. Проверьте синтаксис PHP. Ошибка в одном файле может дать белый экран или критическую ошибку.
4. Включите debug.log. Так можно увидеть warning, notice и fatal error после активации.
5. Проверьте структуру плагина. Разделите админку, фронтенд, AJAX, базу, assets и вспомогательные функции.
6. Проверьте безопасность. Nonce, права пользователей, sanitization, escaping, SQL prepare.
7. Проверьте AJAX и REST API. Кто может вызвать endpoint, какие данные принимает, что возвращает при ошибке.
8. Проверьте базу данных. Таблицы, индексы, wp_options, autoload, миграции, удаление данных.
9. Проверьте нагрузку. Нет ли запросов в циклах, загрузки всех записей сразу, внешних API на каждом открытии страницы.
10. Проверьте совместимость. WordPress, PHP, тема, WooCommerce, кеш, security-плагины, мультиязычность.
11. Проверьте сценарии пользователей. Администратор, редактор, менеджер магазина, гость, авторизованный пользователь.
12. Проверьте отключение и удаление. Плагин должен отключаться без поломки сайта.

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

Код

Важно: код ниже нужен для диагностики и примеров проверки. Перед изменением wp-config.php, functions.php, кастомного плагина или базы данных сделайте backup. Не включайте вывод ошибок посетителям сайта.

Куда вставлять: в файл wp-config.php, выше строки /* That’s all, stop editing! */. Код включает запись ошибок в debug.log, но не показывает ошибки пользователям.

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);
@ini_set('display_errors', 0);

После этого проверьте файл:

/wp-content/debug.log

Проверка синтаксиса PHP из терминала. Команды запускаются локально или на сервере в папке плагина:

php -l my-plugin.php
find . -name "*.php" -print0 | xargs -0 -n1 php -l

Проверка плагина через WP-CLI. Команды выполняются из корня WordPress-сайта:

wp plugin list
wp plugin activate plugin-folder-name
wp plugin deactivate plugin-folder-name
wp option get siteurl
wp option get home

Быстрый поиск опасных мест в AI-сгенерированном плагине. Команды запускаются в папке плагина:

grep -R "$_POST" . -n
grep -R "$_GET" . -n
grep -R "$_REQUEST" . -n
grep -R "$wpdb->query" . -n
grep -R "$wpdb->get_results" . -n
grep -R "wp_ajax_" . -n
grep -R "add_shortcode" . -n
grep -R "wp_redirect" . -n
grep -R "eval(" . -n
grep -R "base64_decode" . -n

Важно: найденная строка не всегда означает ошибку. Проверяйте контекст: есть ли nonce, проверка прав, sanitization, escaping и $wpdb->prepare().

Пример безопасного AJAX-обработчика. Куда вставлять: в главный файл плагина или отдельный PHP-файл, подключённый внутри плагина.

add_action('wp_ajax_sc_plugin_save_settings', 'sc_plugin_save_settings');

function sc_plugin_save_settings() {
    if (!current_user_can('manage_options')) {
        wp_send_json_error(array(
            'message' => 'Недостаточно прав.'
        ), 403);
    }

    check_ajax_referer('sc_plugin_settings_nonce', 'nonce');

    $title = isset($_POST['title']) ? sanitize_text_field(wp_unslash($_POST['title'])) : '';

    if ($title === '') {
        wp_send_json_error(array(
            'message' => 'Поле title пустое.'
        ), 400);
    }

    update_option('sc_plugin_title', $title, false);

    wp_send_json_success(array(
        'message' => 'Настройки сохранены.'
    ));
}

Пример jQuery-запроса для WordPress. Куда вставлять: в JS-файл плагина или временно в админский шаблон для диагностики. В реальном плагине nonce лучше передавать через wp_localize_script().

jQuery(document).on('click', '.sc-plugin-save-button', function(e) {
    e.preventDefault();

    var title = jQuery('.sc-plugin-title').val();
    var nonce = jQuery('.sc-plugin-nonce').val();

    jQuery.ajax({
        url: '<?php echo admin_url("admin-ajax.php") ?>',
        type: 'POST',
        dataType: 'json',
        data: {
            action: 'sc_plugin_save_settings',
            nonce: nonce,
            title: title
        },
        success: function(response) {
            if (response.success) {
                console.log(response.data.message);
            } else {
                console.log(response.data.message);
            }
        },
        error: function(xhr) {
            console.log('Ошибка AJAX:', xhr.status);
        }
    });
});

Пример проверки SQL-запроса. Куда вставлять: в PHP-файл плагина, где выполняется выборка данных.

function sc_plugin_get_items_by_status($status) {
    global $wpdb;

    $status = sanitize_text_field($status);

    if ($status === '') {
        return array();
    }

    $table_name = $wpdb->prefix . 'sc_plugin_items';

    return $wpdb->get_results(
        $wpdb->prepare(
            "SELECT id, title, status, created_at
             FROM {$table_name}
             WHERE status = %s
             ORDER BY created_at DESC
             LIMIT 100",
            $status
        )
    );
}

После диагностики на рабочем сайте отключите debug-режим:

define('WP_DEBUG', false);
define('WP_DEBUG_LOG', false);
define('WP_DEBUG_DISPLAY', false);

Что обязательно проверить в плагине

1. Главный файл плагина

Проверьте, есть ли корректный заголовок плагина. Без него WordPress может не распознать плагин или неправильно показать его в админке.

/*
Plugin Name: SC Custom Plugin
Description: Custom functionality for WordPress.
Version: 1.0.0
Author: Sites Creator
Text Domain: sc-custom-plugin
*/

Также проверьте, чтобы прямой доступ к PHP-файлам был закрыт:

if (!defined('ABSPATH')) {
    exit;
}

2. Имена функций

Плохой признак — общие имена функций:

• save_settings();
• get_data();
• render_table();
• ajax_handler();
• create_table();

Лучше использовать уникальный префикс:

• sc_plugin_save_settings();
• sc_plugin_get_data();
• sc_plugin_render_table();
• sc_plugin_ajax_handler();
• sc_plugin_create_table();

3. Формы и настройки

Если плагин сохраняет настройки, проверьте:

• есть ли nonce в форме;
• проверяется ли current_user_can();
• данные очищаются перед сохранением;
• вывод настроек экранируется;
• ошибки показываются понятным сообщением;
• настройки не сохраняются в autoload без необходимости.

4. AJAX

Проверьте каждый обработчик wp_ajax_ и wp_ajax_nopriv_. Если обработчик меняет данные, он должен проверять nonce и права пользователя.

Тип AJAX	Что проверить	Риск
wp_ajax_*	nonce, current_user_can(), sanitization	авторизованный пользователь может выполнить лишнее действие
wp_ajax_nopriv_*	ограничения, nonce, rate limit, валидация	гость или бот может спамить запросами
Сохранение настроек	manage_options, check_ajax_referer()	изменение настроек без прав
Загрузка файлов	тип файла, размер, права, nonce	загрузка вредоносных файлов
Удаление данных	права, nonce, подтверждение	потеря данных

5. SQL и база данных

AI часто пишет SQL, который работает на тесте, но плохо выдерживает реальный сайт.

Проверьте:

• используется ли $wpdb->prepare();
• нет ли значений из $_POST и $_GET прямо в SQL;
• есть ли LIMIT для больших выборок;
• нет ли запросов внутри больших циклов;
• учитывается ли $wpdb->prefix;
• создаются ли индексы для часто фильтруемых колонок;
• есть ли dbDelta() для создания и обновления таблиц;
• что происходит при деактивации и удалении плагина.

6. Подключение CSS и JS

Плагин не должен подключать свои скрипты и стили на всех страницах сайта, если они нужны только на одной странице админки или конкретном шорткоде.

Проверьте:

• используется ли wp_enqueue_script();
• используется ли wp_enqueue_style();
• подключаются ли assets только там, где нужны;
• нет ли дубликатов jQuery;
• нет ли конфликта с темой или page builder;
• не ломает ли минификация JS работу плагина.

7. Совместимость с WooCommerce

Если плагин касается WooCommerce, проверяйте не только страницу настроек. Нужно пройти весь путь клиента.

• товар открывается;
• товар добавляется в корзину;
• корзина обновляется;
• checkout работает;
• доставка рассчитывается;
• оплата отображается;
• заказ создаётся;
• статус заказа меняется;
• письма уходят;
• callback или webhook работает;
• WooCommerce logs не показывают новых ошибок.

Как отличить черновик от готового плагина

Признак	Черновик от ChatGPT	Готовый к работе плагин
Структура	один большой файл	логика разделена по файлам
Безопасность	может не быть nonce и прав	есть nonce, current_user_can(), sanitization, escaping
SQL	запросы собраны строками	используется $wpdb->prepare()
Ошибки	ошибки не обрабатываются	есть fallback и понятные сообщения
AJAX	работает только на тесте	проверен в Network, с ролями и ошибками
Производительность	нет лимитов и пагинации	есть LIMIT, пагинация, индексы, кеш где нужно
Поддержка	сложно понять, что менять	есть понятные функции, префиксы и структура
Удаление	непонятно, что остаётся в базе	есть controlled uninstall-логика

Результат

После нормальной проверки плагина должно быть понятно, можно ли ставить его на рабочий сайт, что нужно исправить и какие риски остаются.

• плагин активируется без fatal error;
• debug.log не содержит новых критических ошибок;
• функции имеют уникальные префиксы;
• формы защищены nonce;
• права пользователей проверяются;
• входные данные очищаются;
• вывод экранируется;
• SQL-запросы подготовлены;
• AJAX работает с правильными ответами и статусами;
• CSS/JS подключаются только где нужно;
• плагин не ломает тему и другие плагины;
• WooCommerce-сценарии проверены, если они затронуты;
• плагин можно отключить без поломки сайта;
• понятно, что происходит при удалении плагина;
• есть backup и точка отката.

Дополнительные способы

Проверка через staging

Лучший вариант — установить плагин на копии сайта. Так можно увидеть конфликты с реальной темой, плагинами, WooCommerce, кешем и ролями пользователей без риска для рабочего проекта.

Проверка через Git

Если плагин меняется через ChatGPT несколько раз, ведите Git. Тогда видно, какие строки изменились и можно быстро откатить опасную правку.

Проверка ролей пользователей

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

Проверка на пустых данных

Создайте тест, где таблица пустая, поле не заполнено, API не ответил, пользователь не авторизован, файл не загружен. Хороший плагин должен обрабатывать такие ситуации без белого экрана.

Проверка после обновлений

После установки AI-плагина проверьте сайт после обновления WordPress, темы и ключевых плагинов. Если плагин ломается после обновлений, смотрите порядок восстановления в статье после обновления плагина сломался сайт WordPress.

Частые ошибки

• Ставить плагин сразу на рабочий сайт. Непроверенный AI-код может дать критическую ошибку или сломать админку.
• Проверять только внешний результат. Если кнопка работает, это ещё не значит, что код безопасный.
• Не смотреть debug.log. Плагин может работать, но писать warning и notice, которые позже станут проблемой.
• Игнорировать права пользователей. Админ видит одно, менеджер магазина или гость — другое.
• Не проверять AJAX. Ошибки action, nonce, 400, 403, 500 часто видны только в Network.
• Оставлять SQL без prepare. Это риск безопасности и ошибок данных.
• Не проверять вывод данных. Вывод без escaping может привести к XSS.
• Подключать CSS/JS глобально. Это может замедлить сайт и создать конфликты.
• Не проверять деактивацию. Плагин должен отключаться без поломки сайта.
• Не понимать, что удалится при uninstall. Плагин не должен неожиданно удалять важные данные.

Диагностика проблем

Если плагин уже установлен и ведёт себя нестабильно, ищите проблему по симптомам.

Проблема	Вероятная причина	Что делать
Сайт падает после активации	PHP fatal error, конфликт функции, несовместимость PHP	проверить debug.log, php -l, error_log, переименовать папку плагина
Админка открывается с ошибками	ошибка admin hook, CSS/JS конфликт, capability	проверить wp-admin, консоль, debug.log, роли
AJAX возвращает 400	неверный action, nonce, структура POST	проверить Network, data, check_ajax_referer()
AJAX возвращает 403	нет прав, WAF, security-плагин	проверить current_user_can(), роль, server logs
AJAX возвращает 500	PHP fatal error внутри обработчика	проверить debug.log и error_log
Данные не сохраняются	не совпадают имена полей, sanitize обнуляет значение, SQL-ошибка	логировать входные данные, проверить SQL и wp_options
Данные выводятся криво	нет escaping или неправильная кодировка	проверить esc_html(), esc_attr(), wp_kses()
Сайт стал медленнее	скрипты грузятся везде, SQL без лимитов, API на каждом хите	проверить Query Monitor, Network, SQL, wp_enqueue
WooCommerce начал ломаться	конфликт хуков, кеш, checkout, сессии, оплата	проверить товар, корзину, checkout, оплату, WooCommerce logs

Мини-чеклист проверки AI-плагина

• проверить главный файл и заголовок плагина;
• проверить закрытие прямого доступа через ABSPATH;
• проверить уникальные префиксы функций;
• проверить PHP-синтаксис через php -l;
• активировать плагин на staging;
• включить debug.log;
• проверить nonce в формах;
• проверить current_user_can();
• проверить sanitization входных данных;
• проверить escaping вывода;
• проверить SQL через $wpdb->prepare();
• проверить AJAX в Network;
• проверить REST API, если он есть;
• проверить роли пользователей;
• проверить пустые данные и ошибки API;
• проверить подключение CSS/JS;
• проверить работу с WooCommerce, если плагин его затрагивает;
• проверить отключение плагина;
• проверить uninstall-логику;
• сделать backup после успешной проверки.

FAQ

Как проверить WordPress-плагин, написанный через ChatGPT?

Проверьте плагин на staging-копии: PHP-синтаксис, debug.log, структуру файлов, nonce, права пользователей, sanitization, escaping, SQL через $wpdb->prepare(), AJAX, REST API, CSS/JS, нагрузку, WooCommerce-сценарии, отключение и удаление.

Можно ли ставить плагин от ChatGPT сразу на рабочий сайт?

Не стоит. Сначала сделайте backup и проверьте плагин на тестовой копии. Даже если код выглядит простым, он может вызвать fatal error, конфликт функций, ошибку AJAX или проблему безопасности.

Что самое опасное в AI-плагине для WordPress?

Самые опасные места: SQL без prepare, AJAX без nonce, действия без current_user_can(), вывод без escaping, загрузка файлов без проверки, общие имена функций и отсутствие обработки ошибок.

Как проверить, что плагин безопасен?

Проверьте все входные данные, сохранение, вывод, AJAX, REST API, права пользователей, SQL-запросы, загрузку файлов и логи. Для действий, которые меняют данные, должны быть nonce и проверка прав.

Как понять, что плагин плохо написан?

Признаки: один огромный файл, общие имена функций, нет nonce, нет sanitization, SQL собран строкой, CSS/JS грузятся везде, нет uninstall-логики, нет обработки ошибок, debug.log показывает warning или notice.

Что делать, если после активации плагина сайт упал?

Через FTP/SFTP переименуйте папку плагина в /wp-content/plugins/, проверьте debug.log и error_log. После восстановления не активируйте плагин снова на рабочем сайте без исправления причины.

Как проверить AJAX в плагине?

Откройте DevTools браузера, вкладку Network, выполните действие и проверьте запрос к admin-ajax.php: action, nonce, POST-данные, HTTP-статус, JSON-ответ и ошибки в debug.log.

Нужно ли проверять плагин, если он только выводит шорткод?

Да. Даже шорткод может делать SQL-запросы, выводить пользовательские данные, подключать CSS/JS, ломать верстку или создавать нагрузку. Вывод должен быть экранирован.

Как проверить SQL в AI-плагине?

Ищите $wpdb->query(), $wpdb->get_results(), $wpdb->get_var(), $wpdb->insert(), $wpdb->update(). Проверьте, что данные очищаются, запросы подготовлены через $wpdb->prepare(), есть LIMIT и учитывается $wpdb->prefix.

Когда плагин лучше переписать, а не править?

Если код хаотичный, небезопасный, дублируется, ломается при каждой правке, работает с заказами или персональными данными и не имеет понятной структуры, часто надёжнее переписать критические части.

Вывод

WordPress-плагин, написанный через ChatGPT, можно использовать только после технической проверки. Рабочая кнопка, шорткод или AJAX-запрос ещё не означают, что плагин безопасен, совместим и готов к поддержке.

Безопасный порядок такой: backup, staging, проверка PHP-синтаксиса, debug.log, структура файлов, nonce, права, sanitization, escaping, SQL, AJAX, REST API, CSS/JS, роли пользователей, WooCommerce-сценарии, отключение и uninstall. После такой проверки понятно, можно ли плагин ставить на рабочий сайт или его нужно дорабатывать.