WordPress для Middle: питання на співбесіду

Nonce (wp_nonce_field + check_admin_referer) захищає від CSRF, current_user_can з конкретною здатністю — від перевищення прав, esc_* на виводі — від XSS, $wpdb->prepare — від SQL-інʼєкції. Це чотири різні шари, і жоден не замінює інший.

Шаблони перевизначають копією у `wp-content/themes/{тема}/woocommerce/` зі збереженням шляху й контролем `@version`, логіку чіпляють на хуки WooCommerce, а дані пишуть через CRUD (`$product->update_meta_data()`, `$order->update_meta_data()`), бо при HPOS замовлення більше не живуть у `wp_posts`. Класичний і блоковий checkout мають різні точки розширення.

CPT — це рядок у wp_posts із власним post_type, таксономія — нормалізована багато-до-багатьох звʼязка через term_relationships; таксономія годиться для фільтрів і категоризації, meta — для атрибутів запису, а власна таблиця потрібна, коли даних мільйони або потрібні складні фільтри й свої індекси.

WP-CLI завантажує WordPress у CLI-процесі без HTTP, тому дає скриптований доступ до ядра, плагінів і бази: перенесення через search-replace з коректною обробкою serialize(), запуск WP-Cron із системного crontab і власні команди через WP_CLI::add_command з нормальними exit-кодами для CI.

register_rest_route на хуку rest_api_init: namespace/версія, methods, callback, обовʼязковий permission_callback з current_user_can і args зі sanitize_callback та validate_callback; помилки повертаються як WP_Error зі status.

Сучасний шлях — block.json і register_block_type з шляхом до директорії блоку: метадані, скрипти й стилі описуються декларативно, а PHP-рендер задається через render або render_callback.

Спершу профілювання через Query Monitor, потім persistent object cache у Redis, правильні аргументи WP_Query, індекси або власні таблиці замість meta_query і повне кешування сторінок на рівні nginx.