Вы купили премиум-тему (Avada, Divi, Astra): цвета не совпадают с брендом, шрифты другие, а нужной функциональности нет. Правки через админку не сохраняются после обновления. Редактирование файлов родительской темы — гарантированная потеря всех изменений. Типичные проблемы: несоответствие бренду, медленная загрузка из-за 15+ неиспользуемых скриптов, отсутствие кастомных шорткодов. За 5 лет мы выполнили более 50 проектов по кастомизации, экономя клиентам до 80% времени на повторную настройку. Наше решение — дочерняя тема с сохранением всех возможностей обновления. Гарантируем безопасность: сертифицированные специалисты проверяют каждый этап, минимизируя риски поломки.
Как кастомизировать тему без потери обновлений?
Единственный правильный способ — дочерняя тема. Все изменения вносятся в неё, родительская остаётся нетронутой. При обновлении родительской темы ваши правки не затрагиваются. Создание дочерней темы занимает 10 минут и требует двух файлов: style.css и functions.php.
/* style.css */
/*
Theme Name: My Theme Child
Template: parent-theme-folder-name
Version: 1.0.0
*/
/* functions.php */
<?php
add_action('wp_enqueue_scripts', function () {
wp_enqueue_style('parent-style', get_template_directory_uri() . '/style.css');
wp_enqueue_style('child-style', get_stylesheet_directory_uri() . '/style.css', ['parent-style']);
});
Чтобы переопределить шаблон, скопируйте нужный файл из родительской темы в дочернюю, сохраняя структуру папок. WordPress автоматически использует вашу версию.
parent-theme/template-parts/post/content-single.php → child-theme/template-parts/post/content-single.php
- Создайте папку дочерней темы в
/wp-content/themes/.
- Добавьте
style.css с заголовком, указав Template: parent-theme-folder-name.
- Создайте
functions.php для подключения стилей.
- Активируйте дочернюю тему в админке.
Кастомизация через Customizer API
Customizer API позволяет управлять настройками бренда прямо из админки. Пример добавления цвета акцента:
add_action('customize_register', function (WP_Customize_Manager $wp_customize) {
$wp_customize->add_section('brand_settings', [
'title' => 'Настройки бренда',
'priority' => 30,
]);
$wp_customize->add_setting('brand_accent_color', [
'default' => '#0066cc',
'sanitize_callback' => 'sanitize_hex_color',
'transport' => 'postMessage',
]);
$wp_customize->add_control(new WP_Customize_Color_Control($wp_customize, 'brand_accent_color', [
'label' => 'Цвет акцента',
'section' => 'brand_settings',
]));
});
add_action('wp_head', function () {
$color = get_theme_mod('brand_accent_color', '#0066cc');
echo '<style>:root { --accent: ' . esc_attr($color) . '; }</style>';
});
Так вы сможете менять цвета, шрифты и логотип без редактирования кода.
Подробнее о настройке шрифтов
Чтобы заменить шрифты, отключите шрифты родительской темы через хук parent_theme_enqueue_fonts и подключите свои через wp_enqueue_style. Например:
add_action('wp_enqueue_scripts', function() {
// Отключаем шрифты родительской темы
wp_dequeue_style('parent-fonts');
// Подключаем свои
wp_enqueue_style('custom-fonts', 'https://fonts.googleapis.com/css2?family=Inter:wght@400;700&display=swap');
}, 20);
Это гарантирует, что ваши шрифты будут использоваться, а родительские — нет.
Замена шрифтов и CSS-переменные
Вместо переопределения каждого класса задайте CSS-переменные в дочерней теме. Это сокращает объём CSS на 30–50% и упрощает поддержку. Пример:
:root {
--color-primary: #1a1a2e;
--color-accent: #e94560;
--font-heading: 'Montserrat', sans-serif;
--font-body: 'Inter', sans-serif;
--border-radius: 8px;
}
Затем используйте переменные в своих стилях. При необходимости смените шрифт — достаточно изменить значение одной переменной.
Почему дочерняя тема — единственный безопасный способ?
Дочерняя тема сохраняет обновления. Без неё все изменения теряются после первого обновления. В среднем это экономит 2–5 дней работы в год. Кроме того, дочерние темы легко переносить между сайтами: достаточно скопировать папку. Они совместимы со всеми плагинами и не вызывают конфликтов.
| Критерий |
Дочерняя тема |
Прямое редактирование |
| Сохранение обновлений |
Да |
Нет |
| Время настройки |
2–4 дня |
1 день (но теряется при обновлении) |
| Безопасность |
Высокая |
Низкая |
| Поддержка плагинов |
Полная |
Частичная |
| Переносимость |
Легко переносится |
Требует повторной настройки |
Дочерняя тема в 5 раз надёжнее прямого редактирования. Она позволяет обновлять родительскую тему без потери изменений.
Что делать, если тема сломалась после обновления?
Если после обновления родительской темы сайт перестал работать, причина — правки в родительских файлах. Восстановите исходные файлы темы из бэкапа, создайте дочернюю тему и перенесите кастомизации. В будущем обновляйте только родительскую тему, а правки вносите в дочернюю. Это предотвращает поломки.
Типичные ошибки при кастомизации
-
Редактирование файлов родительской темы. Это приводит к потере изменений при обновлении. Всегда используйте дочернюю тему.
-
Игнорирование CSS-переменных. Вместо переопределения 20+ классов задайте 5 переменных. Это упростит поддержку.
-
Отсутствие документации. Даже краткая запись о внесённых изменениях ускорит будущие доработки в 2 раза.
Что входит в работу по кастомизации
- Аудит текущей темы: выявление узких мест, неиспользуемого кода (до 30% кода можно удалить)
- Создание дочерней темы с полным сохранением обновлений
- Перенос кастомизаций: цвета, шрифты, шаблоны, шорткоды
- Настройка Customizer API для удобного управления настройками бренда
- Оптимизация CSS и JS: сборка, минификация, tree-shake (снижение веса на 40–60%)
- Документирование всех изменений и передача доступов
Сроки и стоимость кастомизации WordPress-темы
| Вид работ |
Срок |
Примечание |
| Базовая настройка цветов, шрифтов, логотипа |
2–3 дня |
Только дочерняя тема |
| Переопределение шаблонов и шорткодов |
3–5 дней |
Требуется анализ структуры |
| Полная кастомизация с новыми функциями |
5–10 дней |
Включает разработку кастомных блоков |
| Аудит и оптимизация производительности |
2–4 дня |
Отдельная услуга |
Стоимость рассчитывается индивидуально. Свяжитесь с нами для точной оценки вашего проекта. Закажите кастомизацию готовой темы WordPress — получите уникальный дизайн с сохранением возможности обновлений. Получите консультацию, чтобы обсудить детали.
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 запросы. Полный отчёт включает рекомендации по каждому компоненту.
Процесс работы
-
Аудит и аналитика. Анализ существующей кодовой базы, конкурентов, технических требований. Для нового сайта — семантическое ядро, UX-прототипирование.
-
Архитектура. Решаем: монолит или headless. Определяем Custom Post Types, Custom Fields (ACF или нативные
register_meta()), таксономии.
-
Разработка. Локальное окружение: Docker (nginx + php-fpm + MariaDB). Git с pre-commit хуками для PHP CS Fixer и ESLint. Деплой через WP-CLI + SSH или Buddy.works CI/CD.
-
Тестирование. PHPUnit для кастомных плагинов. Playwright для E2E критичных сценариев (добавить в корзину → оформить заказ → подтверждение). Lighthouse CI в пайплайне — падаем, если Performance Score < 85.
-
Деплой и поддержка. Staging через WP Stagecoach или ручной клон. Мониторинг — UptimeRobot + Sentry для PHP ошибок. Обновления плагинов — через WP-CLI в тестовой среде сначала.
Как провести аудит WordPress сайта за 5 шагов?
- Проверьте
wp-config.php — включён ли WP_DEBUG и WP_DEBUG_LOG. В продакшене они должны быть выключены.
- Откройте Query Monitor (или аналоги) и посмотрите количество запросов на главной. Норма — менее 30.
- Запустите Lighthouse — обратите внимание на LCP, CLS, INP. Если LCP > 2.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_Query — posts_per_page => -1 на странице с тысячами записей гарантирует таймаут.
Почему стоит доверить WordPress разработку профессионалам?
Мы на рынке более 10 лет, выполнили 80+ проектов, имеем сертификаты Automattic и опыт работы с WooCommerce на высоконагруженных площадках. Наши решения учитывают все нюансы: от совместимости плагинов до требований Core Web Vitals (рекомендации Google). После завершения проекта вы получаете не просто сайт, а документированную, тестированную и готовую к масштабированию платформу.
Для консультации и оценки вашего проекта — пишите или звоните. Мы отвечаем в течение часа в рабочее время. Закажите аудит уже сегодня.