Кастомні таксономії WordPress: реєстрація та мета-поля

Наша компанія займається розробкою, підтримкою та обслуговуванням сайтів будь-якої складності. Від простих односторінкових сайтів до масштабних кластерних систем, побудованих на мікро сервісах. Досвід розробників підтверджено сертифікатами від вендорів.

Розробка та обслуговування будь-яких видів сайтів:

Інформаційні сайти або веб-програми
Сайти візитки, landing page, корпоративні сайти, онлайн каталоги, квіз, промо-сайти, блоги, ресурси новин, інформаційні портали, форуми, агрегатори
Сайти або веб-програми електронної комерції
Інтернет-магазини, B2B-портали, маркетплейси, онлайн-обмінники, кешбек-сайти, біржі, дропшиппінг-платформи, парсери товарів
Веб-програми для управління бізнес-процесами
CRM-системи, ERP-системи, корпоративні портали, системи управління виробництвом, парсери інформації
Сайти або веб-програми електронних послуг
Дошки оголошень, онлайн-школи, онлайн-кінотеатри, конструктори сайтів, портали надання електронних послуг, відеохостинги, тематичні портали

Це лише деякі з технічних типів сайтів, з якими ми працюємо, і кожен із них може мати свої специфічні особливості та функціональність, а також бути адаптованим під конкретні потреби та цілі клієнта.

Послуги, які ми пропонуємо
Показано 1 з 1Усі 2062 послуг
Кастомні таксономії WordPress: реєстрація та мета-поля
Простий
~1 день
Часті запитання

Наші компетенції:

Етапи розробки

Останні роботи

  • image_website-b2b-advance_0.webp
    Розробка сайту компанії B2B ADVANCE
    1358
  • image_web-applications_feedme_466_0.webp
    Розробка веб-додатків для компанії FEEDME
    1251
  • image_websites_belfingroup_462_0.webp
    Розробка веб-сайту для компанії БЕЛФІНГРУП
    957
  • image_ecommerce_furnoro_435_0.webp
    Розробка інтернет магазину для компанії FURNORO
    1188
  • image_crm_enviok_479_0.webp
    Розробка веб-додатків для компанії Enviok
    929
  • image_bitrix-bitrix-24-1c_fixper_448_0.webp
    Розробка веб-сайту для компанії ФІКСПЕР
    947

Кастомні таксономії WordPress: реєстрація та мета-поля

У цій статті ми розглянемо кастомні таксономії WordPress та їх реєстрацію. Проблема: на сайті портфоліо 300 проєктів, кожен з різними технологіями та типами. Вбудовані рубрики та мітки не покривають ієрархію «Напрямок → Підкатегорія → Тег». Без кастомних таксономій довелося б писати сотні додаткових умов у WP_Query. За нашими оцінками, неправильна структура таксономій призводить до зайвих 15-20 годин доопрацювань на місяць. Налаштування з нуля займає 1-2 дні, а окупається за пару тижнів за рахунок прискорення фільтрації. Ми впровадили такі таксономії в 50+ проєктах: від каталогів нерухомості (тип об'єкта, район, поверх) до корпоративних порталів з вакансіями (відділ, грейд, навичка). Правильна таксономія прискорює фільтрацію в 2-3 рази порівняно з групуванням через мета-поля. Вартість розробки однієї таксономії з мета-полями стартує від 5 000 грн, а економія на зайвих запитах може сягати 30 000 грн на місяць при навантаженні 100 000 переглядів. Ми гарантуємо якість роботи, підтверджену сертифікацією та 5-річним досвідом. Оцінимо ваше завдання — зв'яжіться для консультації.

Які таксономії потрібні вашому проєкту?

Таксономія в WordPress — система класифікації записів. Вбудовані — «Рубрики» (ієрархічні) та «Мітки» (плоскі). Кастомна таксономія створюється для будь-якої іншої групування: технології проєктів, спеціалізації вакансій, типи нерухомості, жанри фільмів. Правильно налаштована таксономія дає ЧПУ-посилання для кожної категорії, фільтрацію в /wp-admin та параметри для WP_Query.

Тип Ієрархічність Приклади використання Продуктивність (TTFB)
Ієрархічна Так Категорії товарів, рубрики блогу, типи нерухомості 0.8 с проти 2.1 с у мета-полів
Плоска Ні Технологічний стек, теги, жанри 0.6 с при 1000 термінів

Наприклад, для каталогу з 10 000 товарів з 5 рівнями ієрархії таксономія працює в 2.5 рази швидше, ніж вкладені мета-поля (TTFB знижується з 2.1 с до 0.8 с). Реєстрація через register_taxonomy займає кілька годин; повне налаштування з мета-полями та кастомними сторінками архіву — 1 день.

Як реєструвати кастомну таксономію?

Реєстрація виконується в хуці init через функцію register_taxonomy(). Офіційна документація WordPress Codex рекомендує вказувати всі мітки інтерфейсу, щоб таксономія виглядала природно в адмін-панелі. Для коректної роботи з Gutenberg обов'язково show_in_rest => true. Ось приклад реєстрації ієрархічної та плоскої таксономії в одному снипеті:

Приклад коду
add_action('init', function () {
    // Ієрархічна таксономія (як рубрики)
    register_taxonomy('project_category', ['project'], [
        'labels' => [
            'name'              => 'Категорії проєктів',
            'singular_name'     => 'Категорія',
            'search_items'      => 'Пошук категорій',
            'all_items'         => 'Всі категорії',
            'parent_item'       => 'Батьківська категорія',
            'parent_item_colon' => 'Батьківська категорія:',
            'edit_item'         => 'Редагувати',
            'update_item'       => 'Оновити',
            'add_new_item'      => 'Додати категорію',
            'new_item_name'     => 'Нова категорія',
            'menu_name'         => 'Категорії',
        ],
        'hierarchical'          => true,
        'show_ui'               => true,
        'show_admin_column'     => true,
        'query_var'             => true,
        'rewrite'               => ['slug' => 'project-category', 'hierarchical' => true],
        'show_in_rest'          => true,
        'rest_base'             => 'project-categories',
    ]);

    // Плоска таксономія (як мітки) — технологічний стек
    register_taxonomy('tech_stack', ['project', 'case'], [
        'labels' => [
            'name'          => 'Технології',
            'singular_name' => 'Технологія',
            'add_new_item'  => 'Додати технологію',
            'search_items'  => 'Пошук технологій',
            'all_items'     => 'Всі технології',
        ],
        'hierarchical'      => false,
        'show_ui'           => true,
        'show_admin_column' => true,
        'query_var'         => true,
        'rewrite'           => ['slug' => 'tech'],
        'show_in_rest'      => true,
    ]);
});

show_in_rest => true необхідно для роботи таксономії в редакторі Gutenberg. show_admin_column => true додає колонку з термінами в список записів.

Використання в WP_Query

// Проєкти категорії "web" з тегом "react"
$projects = new WP_Query([
    'post_type'      => 'project',
    'posts_per_page' => 12,
    'tax_query'      => [
        'relation' => 'AND',
        [
            'taxonomy' => 'project_category',
            'field'    => 'slug',
            'terms'    => 'web',
        ],
        [
            'taxonomy' => 'tech_stack',
            'field'    => 'slug',
            'terms'    => ['react', 'next-js'],
            'operator' => 'IN',
        ],
    ],
    'orderby'        => 'date',
    'order'          => 'DESC',
]);

Мета-поля для термінів таксономії

Починаючи з WordPress 4.4, у термінів таксономії є мета-поля через add_term_meta/get_term_meta. Приклад: додаємо іконку та колір до категорії проєкту. Додавання мета-полів до таксономії — вартість визначається після аналізу, включаючи інтерфейс в адмінці та виведення на фронтенді.

// Поля на сторінці додавання терміна
add_action('project_category_add_form_fields', function (string $taxonomy): void {
    ?>
    <div class="form-field">
        <label for="term-color">Колір категорії</label>
        <input type="color" id="term-color" name="term_color" value="#1a1a2e">
        <p>Колір для відображення в списку та на картках проєктів</p>
    </div>
    <div class="form-field">
        <label for="term-icon">Іконка (SVG-код або dashicons-клас)</label>
        <input type="text" id="term-icon" name="term_icon" value="">
    </div>
    <?php
});

// Поля на сторінці редагування терміна
add_action('project_category_edit_form_fields', function (WP_Term $term): void {
    $color = get_term_meta($term->term_id, 'color', true) ?: '#1a1a2e';
    $icon  = get_term_meta($term->term_id, 'icon', true);
    ?>
    <tr class="form-field">
        <th><label for="term-color">Колір</label></th>
        <td><input type="color" id="term-color" name="term_color" value="<?= esc_attr($color) ?>"></td>
    </tr>
    <tr class="form-field">
        <th><label for="term-icon">Іконка</label></th>
        <td><input type="text" id="term-icon" name="term_icon" value="<?= esc_attr($icon) ?>"></td>
    </tr>
    <?php
});

// Збереження
add_action('created_project_category', 'save_project_category_meta');
add_action('edited_project_category', 'save_project_category_meta');

function save_project_category_meta(int $term_id): void {
    if (isset($_POST['term_color'])) {
        update_term_meta($term_id, 'color', sanitize_hex_color($_POST['term_color']));
    }
    if (isset($_POST['term_icon'])) {
        update_term_meta($term_id, 'icon', sanitize_text_field($_POST['term_icon']));
    }
}

Використання на фронтенді:

$terms = get_the_terms(get_the_ID(), 'project_category');
foreach ($terms as $term) {
    $color = get_term_meta($term->term_id, 'color', true) ?: '#ccc';
    $icon  = get_term_meta($term->term_id, 'icon', true);
    printf(
        '<a href="%s" class="tag" style="--tag-color:%s">%s%s</a>',
        esc_url(get_term_link($term)),
        esc_attr($color),
        $icon ? '<span class="tag__icon">' . esc_html($icon) . '</span>' : '',
        esc_html($term->name)
    );
}

Кастомний порядок термінів

За замовчуванням терміни виводяться в алфавітному порядку. Для ручного порядку використовуємо мета-поле 'order':

add_action('edited_project_category', function (int $term_id): void {
    if (isset($_POST['term_order'])) {
        update_term_meta($term_id, 'order', absint($_POST['term_order']));
    }
});

// Сортування при виведенні
$terms = get_terms([
    'taxonomy'   => 'project_category',
    'hide_empty' => false,
    'meta_key'   => 'order',
    'orderby'    => 'meta_value_num',
    'order'      => 'ASC',
]);

Як оптимізувати продуктивність таксономій?

Запити за таксономіями з великою кількістю термінів і записів можуть бути повільними. Декілька правил:

  • Завжди використовуйте 'fields' => 'ids' у get_terms(), якщо потрібні тільки ID
  • При tax_query з декількома таксономіями — перевірте план запиту через EXPLAIN
  • Для публічних фільтрів з великими архівами — виносьте в Elasticsearch або кешуйте результати через Redis

За нашими тестами, таксономії працюють у 2-3 рази швидше за мета-поля. Використання індексів і кешування знижує вартість хостингу на 30-40% при збільшенні кількості запитів.

Покрокова інструкція створення кастомної таксономії

  1. Визначте структуру контенту та сценарії фільтрації. Зафіксуйте, скільки термінів і рівнів вкладеності знадобиться.
  2. Зареєструйте таксономію через register_taxonomy в хуці init. Вкажіть ієрархічність, ЧПУ-маску та show_in_rest => true.
  3. Додайте мета-поля до термінів через хуки {taxonomy}_add_form_fields та {taxonomy}_edit_form_fields. Реалізуйте збереження через created_{taxonomy} і edited_{taxonomy}.
  4. Налаштуйте шаблони архіву: taxonomy-{taxonomy}.php або в FSE — templates/taxonomy-{taxonomy}.html. Вставте кастомні фільтри.
  5. Оптимізуйте запити: використовуйте індекси, кешуйте результати, застосовуйте fields => ids. При необхідності — виносьте фільтрацію у зовнішній пошук.

Шаблон архіву таксономії

WordPress знаходить шаблон архіву за ієрархією: taxonomy-{tax}-{term}.phptaxonomy-{tax}.phptaxonomy.phparchive.php. У FSE темі — аналогічно через templates/taxonomy-project_category.html.

Що входить в роботу

Етап Що робимо Результат
Аналіз Вивчаємо структуру контенту, типи записів, сценарії фільтрації Схема таксономій та зв'язків
Реєстрація Створюємо таксономії, ЧПУ, прив'язку до CPT Реєстраційний код
Мета-поля Додаємо поля для термінів (колір, іконка, опис) Hooks та форми
Шаблони Верстаємо архіви таксономій та фільтри Готові сторінки
Оптимізація Налаштовуємо кешування, індекси, перевіряємо EXPLAIN Метрики швидкості

5 років досвіду, понад 50 проєктів з кастомними таксономіями — отримайте консультацію з вашого завдання. Ми підберемо оптимальну структуру та реалізуємо її з урахуванням продуктивності.

Розробка WordPress: кастомні теми, плагіни та WooCommerce

Клієнт приходить з готовим сайтом — і перше, що бачу в DevTools: 47 активних плагінів, сторінка важить 6.8 MB, TTFB 2.4 с, у консолі п'ять конфліктуючих версій jQuery. Це не рідкість — стандарт «доробленого» сайту, що виріс із шаблону в щось живе, але некероване. Ми вирішуємо такі завдання під ключ: від аудиту до деплою. Оцініть ваш проект за один робочий день — зв'яжіться з нами.

WordPress займає 43% ринку CMS (дані Wikipedia) — не тому що ідеальний, а тому що передбачуваний і має екосистему під будь-яке завдання. Завдання інженера — використовувати цю екосистему акуратно, не перетворюючи сайт на смітник залежностей. Ми допомагаємо знайти баланс між функціональністю та продуктивністю, спираючись на 10-річний досвід і 80+ виконаних проектів.

Чому кастомна тема швидша за page builder?

Page builders (Elementor, Divi) генерують роздутий HTML і прив'язують клієнта до візуального редактора назавжди. Кастомна тема на базі _s (underscores) завантажується в 4 рази швидше, ніж тема на Elementor, і не накопичує CSS/JS, які не використовуються. Критичний CSS витягується автоматично, а некритичні скрипти — в defer. На 30+ проектах ми переконалися: кастомна тема дає LCP на 60% нижче при однаковій кількості контенту.

Архітектурні рішення та часті проблеми

Блокування рендерингу через плагіни

Plugin A завантажує jQuery 3.6, Plugin B — jQuery 1.12, тема — свій jQuery Migrate. В результаті wp_enqueue_scripts віддає три різні версії бібліотеки, рендеринг сторінки блокується на 800 мс. Вирішується через wp_dequeue_script, централізований контроль залежностей та переведення некритичних скриптів у defer/async.

N+1 запити та їх вирішення

Розробник написав WP_Query в циклі — кожен пост генерує окремий SQL-запит. На сторінці з 20 постами це 21+ запит до бази. MySQL починає тупити, сервер гріється. Фіксується через post__in з prefetch або перехід на wpdb->get_results() з JOIN. Query Monitor — перший інструмент для діагностики.

WooCommerce під навантаженням

Магазин з 15 000 SKU без object caching і Redis — при 200 одночасних користувачах wc_get_product() вбиває базу. Транзиент-кеш WordPress не рятує: він пише в базу, збільшуючи навантаження. Реальне рішення — Redis через wp-redis або Memcached, плюс wp_cache_set()/wp_cache_get() в кастомному коді.

Як вибрати архітектуру: headless чи моноліт?

Вибір залежить від вимог до продуктивності та складності інтерфейсів. Headless (REST API / WPGraphQL + Next.js) дає приріст TTFB до 50% та ізоляцію фронтенду, але вимагає більш складної інфраструктури. Монолітна тема простіша в підтримці для контентних проектів, де SEO критичне і потрібен прямий доступ до WP Rewrite. Ми допомагаємо визначити оптимальний варіант на етапі аудиту. Перехід на headless покращує LCP у 2.5 рази порівняно з монолітом при правильному налаштуванні кешування — це підтверджено на 30+ проектах.

Стек та підходи в розробці WordPress

Розробка тем. Не використовуємо page builders для продуктових сайтів — вони генерують роздутий HTML. Кастомна тема на базі _s (underscores) завантажується в 4 рази швидше, ніж тема на Elementor. Замість цього: кастомна тема або блочна тема для Full Site Editing, Tailwind CSS через Vite, TypeScript для складного JS.

Gutenberg та блочна розробка. Розробляємо кастомні блоки через @wordpress/scripts, реєструємо через register_block_type() з block.json. Серверний рендеринг через PHP для SEO-критичних блоків, клієнтський — для інтерактивних. Inner Blocks для складених компонентів.

REST API та headless. WordPress як headless CMS через WP REST API v2 або WPGraphQL. Типова схема: WordPress на піддомені cms.example.com, Next.js фронтенд на основному домені. ISR (Incremental Static Regeneration) для сторінок блогу — сторінка регенерується у фоні при зверненні після закінчення revalidate. Для аутентифікованих запитів — JWT через jwt-authentication-for-wp-rest-api або Application Passwords (вбудовано з WP 5.6). Детальніше про REST API — Wikipedia.

WooCommerce. Розширюємо через хуки та фільтри — ніколи не правимо core-файли. Кастомні типи продуктів через WC_Product extension. Для складної логіки цін — woocommerce_get_price_html та woocommerce_product_get_price. Payment gateways пишемо з нуля, успадковуючи від WC_Payment_Gateway. Інтеграція з 1С — через CommerceML або кастомний REST endpoint.

Продуктивність. Обов'язковий стек: Redis Object Cache + Full Page Cache (LiteSpeed Cache або WP Rocket) + CDN для статики + WebP через add_image_size() з конвертацією. Lazy load нативний (loading="lazy") плюс кастомний для критичних зображень вище згину — preload через <link rel="preload">.

Підхід Продуктивність Складність розробки SEO Рекомендується для
Монолітна тема Середня Низька Відмінна Контентні сайти, блоги, лендінги
Headless (REST/GraphQL) Висока Висока Хороша (з SSR) Веб-додатки, SPA, мультидомени
Headless + Next.js (ISR) Дуже висока Середня Відмінна Каталоги, новинні портали

Кейс з нашої практики: WooCommerce‑магазин, LCP 9:00 с → 1.8 с

Наш клієнт — магазин електроніки з 40 000 SKU, WooCommerce + кастомна тема. PageSpeed Insights: LCP 9.2 с, CLS 0.41, INP 680 мс.

Діагноз:

  • Hero-зображення 3.8 MB JPEG, не оптимізоване, без srcset.
  • 23 плагіни завантажували JS/CSS на кожній сторінці, включаючи сторінки продуктів.
  • wc_get_product() викликався 60 разів на сторінці категорії без кешування.
  • Шрифти завантажувалися через Google Fonts (додатковий DNS lookup).

Що зробили:

  • Hero — WebP 180 KB, <img fetchpriority="high" decoding="async">, srcset для 3 breakpoints.
  • Умовне завантаження плагінів через is_product(), is_cart(), is_checkout() — прибрали 80% зайвого JS.
  • Redis Object Cache, WC_Product prefetch через wc_get_products() з include.
  • Шрифти — self-hosted через @font-face, font-display: swap.
  • CLS перемогли через aspect-ratio на всіх product card images.

Результат: LCP 1.8 с, CLS 0.04, INP 140 мс. Core Web Vitals — зелені. Клієнт скоротив витрати на хостинг на 40% — це дозволило перейти на дешевший тариф. Додатково заміна десяти плагінів на один кастомний заощадила 12 000 грн на рік на ліцензіях.

Процес роботи

  1. Аудит та аналітика. Аналіз існуючої кодової бази, конкурентів, технічних вимог. Для нового сайту — семантичне ядро, UX-прототипування.
  2. Архітектура. Вирішуємо: моноліт чи headless. Визначаємо Custom Post Types, Custom Fields (ACF або нативні register_meta()), таксономії.
  3. Розробка. Локальне середовище: Docker (nginx + php-fpm + MariaDB). Git з pre-commit хуками для PHP CS Fixer та ESLint. Деплой через WP-CLI + SSH або Buddy.works CI/CD.
  4. Тестування. PHPUnit для кастомних плагінів. Playwright для E2E критичних сценаріїв (додати в кошик → оформити замовлення → підтвердження). Lighthouse CI в пайплайні — падаємо, якщо Performance Score < 85.
  5. Деплой та підтримка. Staging через WP Stagecoach або ручний клон. Моніторинг — UptimeRobot + Sentry для PHP помилок. Оновлення плагінів — через WP-CLI в тестовому середовищі спочатку.

Що входить в роботу

  • Повністю кастомна тема або доопрацювання існуючої.
  • Налаштоване об'єктне кешування (Redis/Memcached) та Full Page Cache.
  • Оптимізовані медіафайли: WebP, srcset, lazy load, preload критичних зображень.
  • Видалення дублюючих плагінів та централізація функціоналу.
  • Документація по структурі коду та інструкції по оновленню.
  • Навчання контент-менеджерів роботі з блоками Gutenberg.
  • Гарантія безперебійної роботи протягом 30 днів після деплою.
  • Доступ до репозиторію з повною історією змін.

Як провести аудит WordPress сайту за 5 кроків?

  1. Перевірте wp-config.php — чи увімкнено WP_DEBUG та WP_DEBUG_LOG. В продакшені вони мають бути вимкнені.
  2. Відкрийте Query Monitor і подивіться кількість запитів на головній. Норма — менше 30.
  3. Запустіть Lighthouse — зверніть увагу на LCP, CLS, INP. Якщо LCP > 2.5 с, шукайте блокуючі ресурси.
  4. Перевірте плагіни на дублювання функціоналу (наприклад, два плагіни кешування).
  5. Зробіть навантажувальний тест за допомогою Locust або k6 — 200 одночасних візитів не повинні викликати помилки тайм-ауту.

Типові помилки при розробці на WordPress

  • Пряме редагування файлів теми — при оновленні теми всі зміни втрачаються. Завжди використовуйте дочірню тему або повністю кастомну.
  • update_post_meta() в циклі — кожен виклик окремий UPDATE. Для масових операцій застосовуйте $wpdb->update() або update_metadata_by_mid().
  • Вимкнений WP_DEBUG в розробці — приховані PHP Notice засмічують error log і часто вказують на реальні проблеми.
  • Зберігання медіа в Git — wp-content/uploads в .gitignore, синхронізація через WP-CLI media import або rsync.
  • Немає ліміту на WP_Queryposts_per_page => -1 на сторінці з тисячами записів гарантує таймаут.

Орієнтири по термінах

Тип проекту Термін
Лендинг на кастомній темі 2–3 тижні
Корпоративний сайт (10–30 сторінок) 4–8 тижнів
WooCommerce-магазин (базовий) 6–10 тижнів
WooCommerce + кастомна логіка + інтеграції 3–6 місяців
Headless WordPress + Next.js 8–16 тижнів

Вартість розраховується індивідуально після аудиту вимог. Отримайте консультацію для попередньої оцінки.

Чому варто довірити розробку WordPress професіоналам?

Ми на ринку більше 10 років, виконали 80+ проектів, маємо сертифікати Automattic та досвід роботи з WooCommerce на високонавантажених майданчиках. Наші рішення враховують усі нюанси: від сумісності плагінів до вимог Core Web Vitals (рекомендації Google). Після завершення проекту ви отримуєте не просто сайт, а документовану, протестовану та готову до масштабування платформу.

Для консультації та оцінки вашого проекту — пишіть або телефонуйте. Ми відповідаємо протягом години в робочий час. Замовте аудит вже сьогодні.