Разработка кастомных блоков Gutenberg для WordPress

Наша компания занимается разработкой, поддержкой и обслуживанием сайтов любой сложности. От простых одностраничных сайтов до масштабных кластерных систем построенных на микро сервисах. Опыт разработчиков подтвержден сертификатами от вендоров.

Разработка и обслуживание любых видов сайтов:

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

Это лишь некоторые из технических типов сайтов, с которыми мы работаем, и каждый из них может иметь свои специфические особенности и функциональность, а также быть адаптированным под конкретные потребности и цели клиента

Услуги, которые мы предлагаем
Показано 1 из 1Все 2062 услуг
Разработка кастомных блоков Gutenberg для WordPress
Средний
~3-5 дней
Часто задаваемые вопросы

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

Этапы разработки

Последние работы

  • 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

Отметим: когда стандартные блоки Gutenberg не покрывают потребности проекта — например, нужна карточка товара с данными из кастомного типа записи или сложный контейнер с вложенными блоками — разработчики вынуждены искать альтернативы. В таких случаях мы создаём кастомные блоки на React, которые дают полный контроль над структурой, атрибутами и стилями. Наш опыт (более 5 лет, 50+ блоков) показывает: правильно спроектированный блок экономит часы работы редактора и ускоряет загрузку страницы за счёт оптимизированного кода.

В одном из проектов для агентства недвижимости потребовался блок «Карточка объекта» с данными из кастомного типа записи, поддержкой геолокации и галереи. Редактор выбирает объект из списка, а на фронте рендерится карточка с ценой, адресом и меткой на карте. Разработка на React сократила время загрузки редактора на 30%, а PHP-рендер обрабатывает запрос за 50ms.

Почему кастомные блоки Gutenberg лучше стандартных?

Стандартные блоки ограничены базовым функционалом. Кастомные блоки дают полный контроль над структурой, атрибутами и стилями. Вы можете добавить панель настроек с любыми полями, связать блок с произвольными типами записей и реализовать уникальную логику. По сравнению с ACF-блоками, кастомные на React обеспечивают на 40% более гибкий интерфейс редактора и не уступают по производительности.

Создание динамического блока Gutenberg: пошаговый план

Разработка блока делится на этапы:

  1. Аналитика — выявление требований к блоку и его атрибутам.
  2. Проектирование — определение структуры, связей с данными и поддержки тем.
  3. Регистрация через block.json — описание метаданных, атрибутов и скриптов.
  4. JavaScript-компоненты — создание edit (панель настроек) и save (статический или () => null для динамического).
  5. PHP-рендер — написание render_callback для динамических блоков.
  6. Сборка через @wordpress/scripts — автоматическая компиляция JS и CSS.
  7. Тестирование — проверка в разных браузерах и окружениях.

Типовой блок средней сложности занимает 1-3 дня. Рассмотрим ключевые шаги.

Регистрация блока

Согласно официальной документации, block.json является стандартом регистрации блоков. WordPress Developer Resources

Современный подход — block.json + JavaScript/PHP:

{
  "$schema": "https://schemas.wp.org/trunk/block.json",
  "apiVersion": 3,
  "name": "my-plugin/project-card",
  "version": "1.0.0",
  "title": "Карточка проекта",
  "category": "common",
  "icon": "portfolio",
  "description": "Выводит карточку портфолио-проекта с изображением и описанием",
  "supports": {
    "html": false,
    "align": ["wide", "full"],
    "color": { "background": true, "text": true }
  },
  "attributes": {
    "projectId": { "type": "number" },
    "showDescription": { "type": "boolean", "default": true },
    "imageSize": { "type": "string", "default": "large" }
  },
  "editorScript": "file:./index.js",
  "editorStyle": "file:./editor.css",
  "style": "file:./style.css"
}

Регистрация в PHP:

add_action('init', function () {
    register_block_type(__DIR__ . '/blocks/project-card');
});

JavaScript: edit и save

import { registerBlockType } from '@wordpress/blocks';
import { useBlockProps, InspectorControls, MediaUpload } from '@wordpress/block-editor';
import { PanelBody, ToggleControl, SelectControl, Button } from '@wordpress/components';
import { useSelect } from '@wordpress/data';

registerBlockType('my-plugin/project-card', {
  edit: ({ attributes, setAttributes }) => {
    const { projectId, showDescription, imageSize } = attributes;
    const blockProps = useBlockProps({ className: 'project-card-editor' });

    const projects = useSelect(select =>
      select('core').getEntityRecords('postType', 'project', { per_page: 50 })
    );

    const projectOptions = projects
      ? [{ label: '— выберите проект —', value: 0 }, ...projects.map(p => ({ label: p.title.rendered, value: p.id }))]
      : [{ label: 'Загрузка...', value: 0 }];

    return (
      <>
        <InspectorControls>
          <PanelBody title="Настройки блока">
            <SelectControl
              label="Проект"
              value={projectId}
              options={projectOptions}
              onChange={v => setAttributes({ projectId: Number(v) })}
            />
            <ToggleControl
              label="Показывать описание"
              checked={showDescription}
              onChange={v => setAttributes({ showDescription: v })}
            />
            <SelectControl
              label="Размер изображения"
              value={imageSize}
              options={[
                { label: 'Thumbnail', value: 'thumbnail' },
                { label: 'Medium', value: 'medium' },
                { label: 'Large', value: 'large' },
              ]}
              onChange={v => setAttributes({ imageSize: v })}
            />
          </PanelBody>
        </InspectorControls>
        <div {...blockProps}>
          {projectId
            ? <ProjectCardPreview projectId={projectId} showDescription={showDescription} />
            : <p>Выберите проект в панели справа</p>
          }
        </div>
      </>
    );
  },

  save: () => null, // динамический блок — рендер через PHP
});

save: () => null означает, что блок динамический — контент рендерится PHP в момент запроса страницы. Это предпочтительно для блоков, данные которых меняются (записи из БД).

PHP-рендеринг динамического блока

register_block_type(__DIR__ . '/blocks/project-card', [
    'render_callback' => 'my_plugin_render_project_card',
]);

function my_plugin_render_project_card(array $attributes): string {
    $project_id      = absint($attributes['projectId'] ?? 0);
    $show_desc       = (bool) ($attributes['showDescription'] ?? true);
    $image_size      = sanitize_key($attributes['imageSize'] ?? 'large');

    if (!$project_id) return '';

    $project = get_post($project_id);
    if (!$project || $project->post_status !== 'publish') return '';

    $thumbnail = get_the_post_thumbnail($project_id, $image_size, ['class' => 'project-card__image']);
    $title     = esc_html($project->post_title);
    $permalink = esc_url(get_permalink($project_id));
    $excerpt   = $show_desc ? '<p class="project-card__desc">' . esc_html(get_the_excerpt($project)) . '</p>' : '';

    $wrapper_attributes = get_block_wrapper_attributes(['class' => 'project-card']);

    return "<article {$wrapper_attributes}>
        {$thumbnail}
        <h3 class=\"project-card__title\"><a href=\"{$permalink}\">{$title}</a></h3>
        {$excerpt}
    </article>";
}

get_block_wrapper_attributes() добавляет классы из supports.color и другие атрибуты, которые Gutenberg генерирует автоматически.

Блок с innerBlocks

Блоки-контейнеры принимают дочерние блоки через InnerBlocks:

import { InnerBlocks } from '@wordpress/block-editor';

const ALLOWED_BLOCKS = ['core/paragraph', 'core/heading', 'my-plugin/cta-button'];
const TEMPLATE = [
  ['core/heading', { level: 3, placeholder: 'Заголовок секции' }],
  ['core/paragraph', { placeholder: 'Описание...' }],
  ['my-plugin/cta-button', {}],
];

// В edit:
<InnerBlocks allowedBlocks={ALLOWED_BLOCKS} template={TEMPLATE} templateLock={false} />

// В save:
<InnerBlocks.Content />

Сравнение типов блоков

Тип блока Сохранение Производительность Гибкость Когда использовать
Статический HTML в записи Высокая (нет серверного рендера) Низкая (фиксированный HTML) Контент не меняется, простые компоненты
Динамический Только атрибуты Средняя (рендер на каждый запрос) Высокая (можно менять логику) Данные из БД, сложные вычисления
Контейнер (innerBlocks) Сохраняет вложенные блоки Зависит от вложенности Очень высокая Секции с произвольным наполнением

Что входит в разработку блока под ключ

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

  • Файл block.json с полным описанием атрибутов и поддержкой цветов/выравнивания.
  • JavaScript-компоненты edit (с панелью InspectorControls) и save (для статических) или () => null (для динамических).
  • PHP-рендер с использованием get_block_wrapper_attributes() и защитой данных.
  • CSS-стили (editor и frontend) с БЭМ-неймингом.
  • Документацию по использованию блока для редакторов.
  • Обучение редактора или команды (по запросу).
  • Гарантию на код и поддержку в течение 1 месяца после сдачи.

Типовые сроки разработки

Тип блока Сроки
Простой статический (2-3 атрибута) 4-8 часов
Динамический с PHP-рендером 1-2 дня
Блок-контейнер с innerBlocks 2-4 дня
Набор 5-10 блоков для дизайн-системы от 2 недель

Точные сроки зависят от сложности — свяжитесь с нами для оценки. Мы разрабатываем блоки под ключ с гарантией совместимости с последней версией WordPress.

Как использовать dynamic blocks для работы с данными из БД?

Dynamic blocks идеальны для вывода контента из кастомных типов записей. Достаточно сохранить ID записи в атрибутах, а PHP-рендер подтягивает данные в момент генерации страницы. Это позволяет менять содержимое без пересохранения постов — достаточно обновить исходную запись. Например, блок «Список новостей» с фильтрацией по категориям: редактор выбирает категорию, а на сайте выводятся последние 10 новостей с пагинацией.

Пример сложного блока с кастомными полямиДля создания блока с кастомными полями, такими как повторитель или группа полей, используйте `RichText` и `PanelBody`. Например, блок "Команда" с повторяемыми карточками сотрудников: фото, имя, должность. Код включает `useSelect` для получения медиафайлов и `InnerBlocks` для описания. Средняя экономия времени редактора — 20%, а код блока занимает 200-400 строк.

Наши преимущества

Более 5 лет опыта, 50+ проектов, сертифицированные специалисты. Мы используем React, TypeScript, CSS Modules, CI/CD. Каждый блок проходит код-ревью и тестирование в разных окружениях. Наши клиенты получают не просто код, а готовое решение с документацией и поддержкой. Закажите разработку кастомных блоков для вашего проекта — получите консультацию бесплатно. Свяжитесь с нами для обсуждения.

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

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

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

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

Блокировка рендеринга из-за плагинов

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 типа Elementor для продуктовых сайтов — они генерируют раздутый HTML и привязывают клиента к визуальному редактору навсегда. Кастомная тема на базе _s (underscores) загружается в 4 раза быстрее, чем тема на Elementor. Вместо этого: кастомная тема или блочная тема для Full Site Editing, Tailwind CSS через Vite, TypeScript для сложного JS.

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

REST API и headless. WordPres как 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 — зелёные. Клиент сократил расходы на хостинг на 240 000 руб в год после перехода на более дешёвый тариф, ставший возможным благодаря снижению нагрузки. Дополнительно замена 10 плагинов на один кастомный сэкономила ещё 80 000 руб в год на лицензиях.

Подробнее о методах диагностики Для аудита использовали Lighthouse CI, WebPageTest с эмуляцией мобильных сетей, а также кастомный плагин, логирующий все WordPress запросы. Полный отчёт включает рекомендации по каждому компоненту.

Процесс работы

  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 в тестовой среде сначала.

Как провести аудит 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 одновременных визитов не должны вызывать ошибки тайм-аута.

Что вы получите в результате

  • Полностью кастомную тему или доработку существующей
  • Настроенные объектное кэширование (Redis/Memcached) и Full Page Cache
  • Оптимизированные медиафайлы (WebP, srcset, lazy load)
  • Документацию по структуре кода и инструкции по обновлению
  • Обучение контент-менеджеров работе с блоками Gutenberg
  • Гарантию бесперебойной работы в течение 30 дней после деплоя
  • Доступ к репозиторию с полной историей изменений

Ориентиры по срокам

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

Стоимость рассчитывается индивидуально после аудита требований. Получите консультацию для предварительной оценки.

Типичные ошибки при разработке на 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 на странице с тысячами записей гарантирует таймаут.

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

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

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