Вопросы на собеседовании: WordPress-разработчик

Я оставляю ядро WordPress заменяемым, переношу переносимое поведение в плагины, представление в тему, а бизнес-правила скрываю за явными доменными сервисами.

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

Я рассматриваю хуки как адаптеры на границе WordPress, а сами сценарии использования держу в обычных PHP-сервисах.

• Небольшой регистратор связывает именованные callbacks, а конструкторы не регистрируют глобальное поведение скрытым образом.
• Сервисы принимают типизированные входы и возвращают доменные результаты, поэтому тестам PHPUnit не нужен полный bootstrap WordPress.
• Объекты WordPress, например WP_Post, преобразуются на границе и не проникают во все бизнес-правила.

Я использую mu-plugin только для платформенного поведения, которое должно загружаться в каждом запросе и не может отключаться для отдельного сайта.

• Настройка окружения, интеграции хостинга и общесетевые меры безопасности подходят для этой границы лучше, чем необязательные продуктовые функции.
• WordPress загружает только верхнеуровневые файлы mu-plugin, поэтому я использую маленький загрузчик для кода Composer с пространствами имен.
• У mu-plugin нет обычных хуков активации и обновлений из админки, поэтому установка и работа со схемой выполняются инструментами деплоя.

Она превращает ядро WordPress и сторонние плагины в зафиксированные зависимости, а репозиторий становится описанием воспроизводимого приложения.

• composer.lock проходит ревью и попадает в деплой, а wp-content разделяется на код приложения, управляемые пакеты и доступные для записи загрузки.
• Отдельный публичный корень оставляет конфигурацию и vendor-файлы за пределами document root.
• Для приватных или отсутствующих в Composer плагинов нужен репозиторий с аутентификацией или источник артефактов, а не ручная загрузка на production.

Я собираю один артефакт и передаю конфигурацию конкретного окружения во время запуска, а не ветвлю код приложения по окружениям.

• Доступ к базе, соли, API-ключи и настройки хоста приходят из менеджера секретов или переменных окружения.
• wp-config.php объединяет неизменяемые значения по умолчанию с небольшим разрешенным списком переопределений окружения.
• Terraform или Kubernetes владеет инфраструктурными значениями, а опции WordPress остаются контентом только когда редакторам действительно нужно их менять.

Я делаю каждый веб-узел одноразовым и выношу все общее между запросами состояние из его локальной файловой системы и памяти.

• Узлы используют один неизменяемый артефакт кода и подключаются к общим базе данных, объектному кешу и хранилищу медиа.
• Health checks не запускают дорогой рендеринг WordPress, а балансировщик завершает TLS с корректной настройкой доверенных proxy-заголовков.
• Sticky sessions не являются частью дизайна, потому что маскируют связанность состояния и делают failover неравномерным.

Я храню оригиналы и сгенерированные размеры в общем объектном хранилище и раздаю их через CDN.

• Перехват загрузок должен охватывать генерацию метаданных, удаление и пересоздание размеров изображений, а не только копирование оригинала.
• Локальные диски остаются временным кешем, поэтому ни один запрос не зависит от файла, записанного конкретным pod.
• Для приватных файлов используется авторизация и короткоживущие подписанные URL, а не публично читаемый bucket загрузок.

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

• PHP-сессии в плагинах исключаются или переносятся в Redis с явным сроком жизни, если они действительно нужны старой интеграции.
• Nonce и права пользователя остаются задачей WordPress и не требуют привязки на балансировщике.
• Отказ от sticky sessions дает предсказуемую балансировку и позволяет убрать узел без потери состояния пользователя.

Я отключаю WP-Cron, зависящий от запросов, запускаю наступившие события одним управляемым планировщиком, а тяжелую работу переношу в надежную очередь.

• Kubernetes CronJob или планировщик платформы вызывает WP-CLI с фиксированной частотой без гонки всех веб-pod на пользовательском трафике.
• Обработчики очереди атомарно забирают задачи и используют ключи идемпотентности, потому что доставка может повториться.
• Плановые callbacks остаются короткими и записывают повторяемую работу вместо обработки целого каталога в одном PHP-запросе.

Я выбираю по контракту потребителя: REST для стабильных операций над ресурсами, а WPGraphQL, когда клиентам нужны гибкие вложенные графы контента.

• REST имеет полноценную поддержку ядра, понятное HTTP-кеширование и более простые endpoints для записи.
• WPGraphQL сокращает лишнюю загрузку записей, терминов и кастомных полей, но расширение схемы и ограничение стоимости запросов становятся задачами платформы.
• Я не открываю оба варианта без причины, потому что два публичных контракта удваивают работу по авторизации, кешированию и совместимости.

Я моделирую редакционный смысл, а не разметку страницы одного фронтенда, и публикую этот смысл через версионируемую схему.

• Custom post types представляют долговечные сущности, таксономии задают общую классификацию, а структурированные поля заменяют непрозрачные HTML-блоки.
• Переиспользуемые блоки допустимы, если их атрибуты имеют документированную форму API и путь миграции.
• Настройки конкретного представления остаются необязательными, чтобы веб, мобильные и синдикационные клиенты по-разному отображали один контент.

Я выбираю режим для каждого route по свежести, персонализации и возможности кеширования, а не объявляю весь сайт статическим или динамическим.

• Долгоживущие статьи могут использовать статическую генерацию с on-demand revalidation после публикации.
• Сильно персонализированные страницы аккаунта используют серверный рендеринг и обходят общие кеши для пользовательских данных.
• Preview-запросы используют доступ к черновикам и отдельный путь кеша, чтобы неопубликованный контент не попал в публичный вывод.

Я использую короткоживущую подписанную передачу, которая включает preview-режим во фронтенде и загружает ревизию от имени текущего редактора.

• WordPress проверяет право редактора и подписывает целевую запись, ревизию, срок действия и return URL.
• Preview endpoint Next.js проверяет подпись перед установкой HTTP-only cookie режима просмотра.
• Ответы preview приватны и не кешируются, а их API-токен нельзя повторно использовать для публичного просмотра.

Я подбираю аутентификацию под клиент и на каждой границе данных оставляю авторизацию на базе capabilities WordPress.

• Редакторские инструменты на том же origin могут использовать cookie WordPress и REST nonce, потому что у браузера уже есть защищенная сессия.
• Серверные вызовы используют отдельного пользователя с минимальными правами и отзываемым application password либо scoped OAuth-данные, которые хранятся только на сервере.
• Я избегаю долгоживущих JWT в browser storage, потому что отзыв, ротация и риск XSS становятся сложнее.

Я инвалидирую кеш по зависимостям контента после успешной публикации, а TTL использую как страховку, а не основной механизм.

• Обновление записи очищает ее страницу, связанные архивы, страницы таксономий и ключи API-кеша из карты зависимостей.
• WordPress отправляет подписанное событие после фиксации записи, а фронтенд устраняет дубликаты перед on-demand revalidation.
• Широкая очистка CDN остается для изменений схемы или навигации, потому что она выбрасывает слишком много полезного кеша.

WordPress должен владеть канонической идентичностью контента и редакционными SEO-данными, а фронтенд отвечает за их итоговый HTML.

• API явно отдает канонические пути, robots directives, структурированные метаданные и записи редиректов.
• Next.js рендерит видимые серверу head tags и применяет редиректы на edge до возврата страницы.
• Изменение URL создает редирект со старого пути и инвалидирует оба пути, чтобы поисковики не увидели конфликтующие canonical.

Они убирают работу на разных слоях, поэтому я использую все три с отдельными владельцами и правилами инвалидации.

• Redis или Memcached повторно использует полученные из базы объекты, но PHP и рендеринг шаблона все еще выполняются.
• Full-page cache пропускает WordPress для анонимного HTML-ответа, а CDN отдает этот ответ рядом с посетителем.
• Очистка должна затронуть каждый нужный слой, потому что сброс Redis не обновит устаревший HTML на edge.

Я делаю ключ публичного кеша маленьким и явным, а для действительно персональных данных обхожу общий HTML-кеш.

• Локаль, host и ограниченный класс устройства могут менять публичную страницу, если от них зависит ответ.
• Произвольные cookie никогда не входят в ключ, потому что они уничтожают hit rate и могут раскрыть персонализированный вывод.
• Admin bar, корзина и данные аккаунта используют приватные фрагменты или некешируемые routes, а не отдельную full-page версию для каждого пользователя.

Я разрешаю одному worker пересоздать значение, а остальным запросам отдаю устаревшие данные или предлагаю коротко отступить.

• Атомарная блокировка Redis имеет короткую аренду и уникальный токен владельца, чтобы она не зависла и не была снята другим worker.
• Stale-while-revalidate сохраняет полезную страницу во время пересоздания вместо отправки каждого промаха в MySQL.
• К срокам жизни добавляется случайный разброс, чтобы связанные ключи не остыли в одну секунду.

Я использую кастомную таблицу, когда данным нужны реляционные ограничения или запросы, которые общая meta-схема не обслуживает предсказуемо.

• Заказам, бронированиям и журналам событий часто нужны типизированные столбцы, уникальные ключи и составные индексы.
• Posts и meta подходят для редакционного контента, которому полезны ревизии, права и API ядра.
• Вместе с кастомной таблицей появляются repository API, явные версии схемы, правила хранения и область Multisite.