Уся правда про functions.php
Файл functions.php давно обріс міфами. Одні розробники вважають його магічною точкою входу для будь-якого кастому в темі, інші бояться зайвий раз торкатися цього файлу, щоб не «покласти» сайт після чергового оновлення. Правда, як це часто буває у WordPress, знаходиться посередині: functions.php справді дуже важливий, але працює він не як універсальне сховище для всього підряд, а як файл ініціалізації саме вашої активної теми.
Коротко: functions.php — це місце, де тема оголошує свою підтримку можливостей WordPress, підключає стилі та скрипти, реєструє меню, сайдбари, додаткові розміри зображень і власні дрібні інтеграції, які мають існувати лише разом із цією темою.
Що таке functions.php насправді
Якщо говорити простою мовою, functions.php — це PHP-файл активної теми, який підключається WordPress під час завантаження сайту. Він дозволяє темі використовувати хуки, фільтри, функції ядра та власні функції. Саме тому його часто порівнюють із плагіном. Але тут є важлива різниця: код із цього файлу живе лише доти, доки активна саме ця тема.
Тобто якщо сьогодні ви додали в functions.php реєстрацію меню, мініатюр, стилів редактора, кастомний логотип і кілька службових фільтрів, усе це працюватиме. Але щойно ви переключите сайт на іншу тему — цей код просто перестане виконуватися. Саме тому будь-яку логіку, яка повинна пережити зміну теми, треба виносити в окремий плагін.
У який момент WordPress завантажує цей файл
Тут починається найцікавіше. Під час bootstrap-процесу WordPress спочатку піднімає ядро, підключає активні плагіни, а вже потім переходить до теми. Саме тому логіка теми не повинна дублювати те, що краще робити на рівні плагіна або ядра. functions.php завантажується після плагінів і працює як частина поточної теми.
У практичній розробці це означає дві речі. По-перше, не треба намагатися через functions.php будувати повноцінний модульний застосунок без структури. По-друге, все, що пов’язане з підтримкою теми, краще оформлювати через хуки WordPress, а не виконувати «в лоб» у глобальній області файлу.
Правильний базовий приклад — окрема функція налаштування теми, прив’язана до after_setup_theme:
__('Header menu', 'site-theme'),
'footer_menu' => __('Footer menu', 'site-theme'),
));
}
}
add_action('after_setup_theme', 'site_theme_setup');
Цей підхід хороший тим, що тема описує сама себе: які можливості вона підтримує, які розміри мініатюр їй потрібні, які меню повинні з’явитися в адмінці. Саме так functions.php стає конфігураційним і сервісним шаром теми, а не хаотичною збіркою випадкового коду.
Як functions.php пов’язаний із ядром і базою даних
Ось тут часто виникає плутанина. Сам файл functions.php не зберігається в базі даних. Це звичайний фізичний файл на диску в директорії теми. WordPress читає його із файлової системи, коли визначає активну тему та запускає її код.
У базі даних зберігається інше:
- службова інформація про активні плагіни та параметри сайту;
- налаштування теми;
- theme mods, якщо ви використовуєте кастомайзер або API змін теми;
- дані записів, сторінок, мета-полів, медіафайлів і так далі.
Простіше кажучи, functions.php — це код, а база даних — це стан і збережені значення. Якщо ваш код у functions.php викликає get_option(), set_theme_mod(), get_theme_mod() або працює з мета-полями, тоді він уже звертається до БД. Але сам файл при цьому все одно лежить у темі, а не в таблицях MySQL.
Наприклад, ось типовий сценарій: у кастомайзері ви додаєте налаштування кольору, а зберігатися воно буде як theme_mod для активної теми:
add_section('site_theme_colors', array(
'title' => __('Theme colors', 'site-theme'),
'priority' => 30,
));
$wp_customize->add_setting('accent_color', array(
'default' => '#0d6efd',
'type' => 'theme_mod',
'sanitize_callback' => 'sanitize_hex_color',
));
$wp_customize->add_control(new WP_Customize_Color_Control(
$wp_customize,
'accent_color',
array(
'label' => __('Accent color', 'site-theme'),
'section' => 'site_theme_colors',
)
));
});
$accentColor = get_theme_mod('accent_color', '#0d6efd');
Тобто ядро завантажує ваш файл, виконує описані в ньому хуки, а вже через ці хуки ваш код може читати або змінювати дані в базі. Це важливий момент для розуміння продуктивності: не сам факт існування functions.php навантажує сайт, а те, що саме ви в нього поклали.
Важливо: якщо в functions.php без потреби робити важкі запити, ініціалізувати сторонні SDK, тягнути великі файли чи виконувати логіку на кожному хіті, сайт сповільниться. Проблема не у файлі як такому, а у вашій реалізації.
Що дійсно варто класти в functions.php
Добрий орієнтир простий: якщо функціональність безпосередньо описує можливості теми або її відображення, їй місце тут. Наприклад, підтримка featured image, підключення стилів, меню, сайдбари, editor styles, невеликі хелпери для шаблонів, формати постів, кастомний логотип, фільтри довжини excerpt і тому подібне.
| Доречно в functions.php |
Краще винести в плагін |
| add_theme_support() |
Кастомні типи записів, якщо вони мають жити після зміни теми |
| register_nav_menus() |
Shortcode-логіка, яка не залежить від дизайну |
| register_sidebar() |
SEO-модулі, інтеграції API, вебхуки |
| wp_enqueue_style() / wp_enqueue_script() |
Ролі користувачів, бізнес-правила, системні сервіси |
| add_editor_style() |
Універсальні адміністративні модулі |
Окремо варто пам’ятати про правильне підключення стилів і скриптів. Їх не потрібно вставляти напряму через <link> чи <script> у шаблонах, якщо мова йде про нормальну тему. Для цього існує enqueue-механізм WordPress:
get('Version')
);
wp_enqueue_script(
'site-theme-app',
get_stylesheet_directory_uri() . '/assets/js/app.js',
array('jquery'),
wp_get_theme()->get('Version'),
true
);
});
Такий спосіб правильний не лише з точки зору коду. Він дозволяє WordPress контролювати залежності, версії, порядок підключення та сумісність із плагінами. Для теми це значно надійніше, ніж ручне виведення ресурсів.
Мініатюри, сайдбари, editor styles — класичні задачі для functions.php
Ще одна сильна сторона цього файлу — все, що стосується оформлення контенту. Якщо тема повинна підтримувати віджети, мати власний сайдбар або стилізований редактор TinyMCE / Classic Editor, усе це логічно оголошувати саме тут.
__('Main sidebar', 'site-theme'),
'id' => 'main-sidebar',
'description' => __('Widgets in this area will be shown in the sidebar.', 'site-theme'),
'before_widget' => '',
'before_title' => '',
));
});
add_action('after_setup_theme', function () {
add_editor_style('editor-style.css');
});
Це той випадок, коли functions.php ідеально відповідає своїй ролі: він не просто запускає код, а описує, як тема повинна поводитися всередині WordPress.
Що не варто тягнути в цей файл
Головна помилка багатьох сайтів — перетворити functions.php на міні-фреймворк без архітектури. У нього додають кастомні типи записів, REST-маршрути, Telegram-інтеграції, CRM-синхронізацію, платіжну логіку, шорткоди, адмінські сторінки, генерацію XML, cron-задачі та ще десяток речей. Формально все це може працювати. Але підтримувати такий сайт із часом стає все дорожче.
Якщо функціональність повинна жити незалежно від теми, її краще винести в окремий плагін. Мінімальний каркас такого плагіна виглядає так:
<?php
/**
* Plugin Name: Site Functionality
* Description: Site-specific functionality that should not depend on the active theme.
* Version: 1.0.0
* Author: Your Name
*/
defined('ABSPATH') || exit;
add_action('init', function () {
// Register post types, taxonomies, shortcodes, REST routes, etc.
});
Це значно правильніше для довготривалої підтримки. Тема відповідає за відображення, плагін — за функціональність. Такий поділ економить нерви і при редизайні, і при перенесенні сайту, і при командній розробці.
Як тримати functions.php чистим і керованим
Навіть якщо весь код об’єктивно належить темі, не треба складати його в один гігантський файл на тисячу рядків. Хороша практика — залишити в functions.php лише підключення частин і базову ініціалізацію.
<?php
require_once get_template_directory() . '/inc/theme-setup.php';
require_once get_template_directory() . '/inc/enqueue.php';
require_once get_template_directory() . '/inc/widgets.php';
require_once get_template_directory() . '/inc/customizer.php';
require_once get_template_directory() . '/inc/template-tags.php';
У такій структурі functions.php стає зрозумілим навіть через рік. Ви одразу бачите, де ініціалізація теми, де стилі, де віджети, де кастомайзер, а де шаблонні хелпери. Це маленьке рішення дає великий виграш у підтримуваності.
Підсумок
functions.php — це не смітник і не чарівна паличка. Це службовий файл активної теми, через який вона повідомляє WordPress, які можливості підтримує, які ресурси підключає і як повинна інтегруватися з ядром. Він тісно пов’язаний із життєвим циклом теми, але не підміняє собою плагіни, модулі або архітектуру проєкту.
Якщо використовувати його за призначенням, він робить тему акуратною, зрозумілою й передбачуваною. Якщо ж складати туди все підряд, то рано чи пізно functions.php перетвориться на джерело багів, конфліктів і болючих рефакторингів. Тому найкраща стратегія проста: усе, що стосується теми — залишаємо в темі; усе, що стосується бізнес-логіки — переносимо в плагін або окремий модуль.