Хочешь ли работать с WordPress?

Мой взгляд на работу с WordPress как PHP Backend-разработчика

Как опытный PHP-разработчик с более чем 10-летним стажем, мой ответ на этот вопрос неоднозначен и зависит от конкретного контекста проекта. WordPress — это инструмент, и как любой инструмент, он имеет свою область эффективного применения.

Когда я готов работать с WordPress

Я открыт к работе с WordPress в следующих сценариях:

Для контент-ориентированных проектов:

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

При условии современного подхода к разработке:

// Пример: Работа с WordPress через Composer и современные практики
require_once __DIR__ . '/vendor/autoload.php';

// Использование WordPress как компонента, а не монолита
$wp = new WordPress\Application();
$wp->useTheme('modern-theme');
$wp->boot();

Для проектов с определенными требованиями:

• Сроки и бюджет ограничены
• Требуется огромное количество готовых плагинов и тем
• Проект уже существует на WordPress и требует поддержки/развития

Мои основные опасения и ограничения

Архитектурные проблемы:

• Глобальное состояние — чрезмерное использование глобальных переменных ($wpdb, $post, etc.)
• Наследование вместо композиции в темах и плагинах
• Отсутствие четкого разделения ответственности

Технический долг и безопасность:

// Типичная проблема WordPress - SQL-инъекции в старом коде
$unsafe_query = "SELECT * FROM {$wpdb->posts} WHERE ID = " . $_GET['id'];
// Вместо этого должно быть:
$safe_query = $wpdb->prepare("SELECT * FROM {$wpdb->posts} WHERE ID = %d", $_GET['id']);

Производительность:

• Большое количество ненужных запросов к БД
• Отсутствие эффективного кэширования "из коробки"
• Проблемы с масштабированием под высокие нагрузки

Мой подход к современной WordPress-разработке

Если работать с WordPress, то только с применением современных практик:

Использование современных инструментов:

• Composer для управления зависимостями
• Bedrock для улучшенной структуры проекта
• Sage или аналоги для тем на основе современных фронтенд-инструментов

Следование лучшим практикам:

• Разделение логики и представления
• Использование хуков (actions/filters) вместо модификации ядра
• Соблюдение стандартов кодирования (WPCS)
• Написание тестируемого кода

// Пример: Современный подход к созданию плагина
namespace MyCompany\WordPressPlugin;

class ProductManager {
    private $repository;
    
    public function __construct(ProductRepository $repository) {
        $this->repository = $repository;
        add_action('init', [$this, 'registerPostType']);
    }
    
    public function registerPostType() {
        register_post_type('product', [
            'labels' => ['name' => __('Products')],
            'public' => true,
            'show_in_rest' => true // Поддержка Gutenberg
        ]);
    }
}

Альтернативы, которые я рассматриваю

Для различных задач я также рассматриваю:

1. Laravel — для сложных бизнес-приложений
2. Symfony — для enterprise-решений
3. Headless CMS + отдельный фронтенд — для SPA/PWA
4. Самописные решения на микрофреймворках — для специфичных задач

Итоговый ответ

Да, я готов работать с WordPress, но с важными оговорками:

• Для правильных проектов (контентные сайты, а не сложные веб-приложения)
• С применением современных подходов к разработке
• С пониманием ограничений платформы и готовностью их обходить
• При условии, что проект не превратится в "зоопарк плагинов"

Мой опыт позволяет мне не просто "делать на WordPress", а архитектурно мыслить даже в рамках этой CMS, создавая поддерживаемые, безопасные и производительные решения. Я вижу ценность WordPress в его экосистеме и простоте для конечных пользователей, но как разработчик я всегда стремлюсь к чистому коду и правильным архитектурным решениям, независимо от платформы.

В конечном счете, решение о выборе WordPress должно быть осознанным технологическим выбором, а не данью традиции или единственно известным вариантом.