Разработка кастомного плагина для Pico CMS под ключ

Зачем нужен кастомный плагин для Pico CMS

Представьте: вам нужно добавить на все страницы Pico CMS кастомную форму обратной связи, которая отправляет данные во внешнюю CRM. Штатными средствами — только Twig-партиалы и ручная обработка. Без плагина придётся править ядро, что чревато конфликтами при обновлении. Правильное решение — написать изолированный PHP-плагин, подключаемый через Composer. Мы занимаемся этим более чем в 50 проектах — от простых редиректов до полноценных корпоративных порталов.

Редактирование ядра Pico напрямую — путь к техническому долгу. При следующем обновлении CMS ваши изменения перезапишутся, а если вы забудете, что правили, — сайт сломается. Плагин же живёт в отдельной директории, подключается через Composer и не трогает ядро. Это стандартная практика в современной PHP-разработке.

Согласно официальной документации Pico, "плагины являются основным способом расширения функциональности" (https://github.com/picocms/Pico).

Как работает система событий Pico

Каждый плагин Pico — это класс, наследующий AbstractPicoPlugin. Он подписывается на события, которые CMS генерирует в строгом порядке: от загрузки конфига до рендеринга Twig-шаблона. Методы-обработчики получают аргументы по ссылке (&$variable), что позволяет модифицировать данные на лету.

<?php

class MyPlugin extends AbstractPicoPlugin
{
    const API_VERSION = 3;

    protected $enabled = true;

    public function onConfigLoaded(array &$config): void
    {
        if (!isset($config['my_plugin'])) {
            $config['my_plugin'] = ['option' => 'default'];
        }
    }

    public function onMetaHeaders(array &$headers): void
    {
        $headers['redirect'] = 'Redirect';
        $headers['auth_required'] = 'AuthRequired';
    }

    public function onPageRendering(string &$templateName, array &$twigVariables): void
    {
        $meta = $twigVariables['meta'];
        if (!empty($meta['redirect'])) {
            header('Location: ' . $meta['redirect'], true, 302);
            exit;
        }
    }
}

Файл кладётся в plugins/MyPlugin/MyPlugin.php. Стандартная структура директории:

plugins/
└── MyPlugin/
    ├── MyPlugin.php
    ├── config.yml.template
    └── README.md

Какие события используются чаще всего?

Вот ключевые точки входа для Pico 3.x. Мы используем их в 90% проектов.

Пример из практики: плагин авторизации по IP

public function onConfigLoaded(array &$config): void
{
    $this->allowedIps = $config['ip_restrict']['allowed'] ?? [];
    $this->restrictedPaths = $config['ip_restrict']['paths'] ?? [];
}

public function onRequestUrl(string &$url): void
{
    $clientIp = $_SERVER['REMOTE_ADDR'] ?? '';
    foreach ($this->restrictedPaths as $path) {
        if (str_starts_with($url, $path)) {
            if (!in_array($clientIp, $this->allowedIps, true)) {
                header('HTTP/1.1 403 Forbidden');
                echo 'Access denied';
                exit;
            }
        }
    }
}

Такой плагин полезен для закрытия админ-панели или staging-окружения. Он работает на раннем этапе — onRequestUrl — и блокирует доступ до начала обработки контента, что экономит ресурсы.

Шорткоды в Pico: как добавить?

Pico не поддерживает шорткоды из коробки — их реализуют через onContentParsed:

public function onContentParsed(string &$content): void
{
    $content = preg_replace_callback(
        '/\[youtube\s+id="([a-zA-Z0-9_-]+)"\]/',
        static function (array $matches): string {
            $id = htmlspecialchars($matches[1], ENT_QUOTES);
            return sprintf(
                '<div class="video-embed"><iframe src="https://www.youtube.com/embed/%s" '
                . 'allowfullscreen loading="lazy" title="YouTube video"></iframe></div>',
                $id
            );
        },
        $content
    );
}

Типы плагинов: что мы умеем?

Плагин на Pico разрабатывается в 3 раза быстрее, чем аналогичное расширение для WordPress, за счёт простой архитектуры событий и минималистичного ядра.

Какие ошибки допускают при разработке плагинов Pico?

1. Неправильный порядок событий: например, попытка использовать onContentParsed до onPageRendering — контент ещё не обработан.
2. Отсутствие проверки на существование массива: $config['my_plugin'] может не быть — используйте ??.
3. Использование глобальных переменных вместо переданных по ссылке: это ломает изоляцию.
4. Забытый exit после редиректа: скрипт продолжает выполнение, и вы получите ошибку заголовков.
5. Отсутствие тестов: плагин может сломаться при обновлении Pico.

Процесс разработки

Мы следуем чёткому регламенту, чтобы вы получили предсказуемый результат:

1. Анализ — вы описываете задачу, мы уточняем детали и оцениваем сроки.
2. Проектирование — определяем список событий, структуру конфига и Twig-переменные.
3. Разработка — пишем код на PHP 8.1+ с учётом PSR-12, покрываем тестами PHPUnit.
4. Интеграционное тестирование — проверяем плагин на вашем хостинге или в среде, приближенной к продакшену.
5. Сдача — передаём исходный код с лицензией MIT, документацию, конфиг-шаблон и отчёт о тестировании.

Что входит в работу

• Исходный код плагина с поддержкой Composer-установки
• README с описанием установки и настройки
• Пример конфига в YAML
• Юнит-тесты (PHPUnit) с покрытием не менее 80%
• 30 дней бесплатной поддержки: исправление багов, консультации

Гарантии и поддержка

Мы гарантируем совместимость с последними версиями Pico и PHP, отсутствие конфликтов с другими плагинами благодаря изолированной архитектуре. Каждый плагин проходит код-ревью и статический анализ. Если у вас есть нестандартная задача — напишите нам, обсудим решение. Получите консультацию по вашему проекту — определим необходимые события и сроки за 1 час.

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

Headless CMS: Strapi, Directus, Sanity, Contentful, Drupal

Традиционная CMS хороша до момента, когда дизайнер говорит «хочу анимацию при скролле с parallax», фронтенд — «нам нужен React», а SEO-специалист — «почему TTFB 3.4 секунды». В этот момент монолитная архитектура начинает мешать всем сразу. Я сталкивался с этим десятки раз: сайт на WordPress с ACF разрастается до 47 плагинов, админка тормозит, а каждый редизайн превращается в переписывание шаблонов.

Headless CMS отделяет управление контентом от его представления. Редакторы работают в удобном интерфейсе, разработчики получают данные через API и строят фронтенд на любом стеке. Звучит просто. На практике — выбор CMS, моделирование данных и настройка API занимают значительную часть проекта. За более чем 7 лет мы провели более 50 внедрений — расскажу, как не наступить на типичные грабли.

Почему headless CMS выгоднее монолита?

Монолитная CMS (WordPress, Joomla, Drupal в классическом режиме) смешивает бэкенд и фронтенд. Любое изменение вёрстки — это изменение шаблонов, часто с риском поломать админку. Headless даёт свободу: фронтенд на React, Vue или Svelte, а контент живёт отдельно. Результат — скорость загрузки (LCP часто падает с 4-6 с до 1-1,5 с), безопасность (нет публичного доступа к админ-панели), масштабирование (контент отдаётся через CDN без нагрузки на сервер). Плюс возможность переиспользовать контент в мобильных приложениях, киосках, email-рассылках через единый API.

Какую headless CMS выбрать под проект?

Нет универсального инструмента. Выбор зависит от команды, сложности контента и инфраструктуры. Разберём ключевые варианты.

Strapi — open-source, self-hosted, Node.js. Подходит командам, которым нужен контроль над данными и возможность кастомизации API. Плагинная архитектура позволяет добавлять кастомные маршруты, middleware, lifecycle hooks. REST и GraphQL из коробки. Разворачивается за час — в 3 раза быстрее Drupal. Слабое место — версии v4 и v5 несовместимы между собой, миграция болезненная. Наш опыт показывает: для стартапов и средних проектов Strapi — оптимальный баланс гибкости и скорости.

Directus — тоже open-source, но другой подход: не генерирует схему, а оборачивает существующую базу данных (PostgreSQL, MySQL, SQLite) в REST/GraphQL API. Если база данных уже есть — Directus подключается к ней без миграций. Удобно для проектов, где данные уже живут в PostgreSQL и нужен быстрый admin UI + API. Экономия времени на этапе интеграции — до 30%.

Sanity — облачная CMS с real-time редактором. Отличительная черта — GROQ (Graph-Relational Object Queries), собственный язык запросов, который мощнее REST для сложных связей между документами. Portable Text для структурированного контента. Подходит для медиа, издательств, маркетинговых сайтов с нестандартными редакционными процессами. Гарантирует скорость даже при 500+ одновременных редакторах — проверено на проектах с ежеминутным обновлением ленты новостей.

Contentful — enterprise облачная CMS. Сильная сторона — локализация (до 1000 локалей), богатый SDK для всех платформ, Contentful Apps для кастомных UI. Слабая — цена при масштабировании и ограниченная гибкость моделей данных по сравнению с open-source альтернативами.

Drupal — не headless в чистом виде, но с модулем JSON:API и GraphQL превращается в мощный API-first бэкенд. Сильная сторона — зрелость, гранулярные права доступа, enterprise-клиенты (NASA, weather.com). Порог входа высокий, для сложных государственных или корпоративных порталов альтернатив мало. Мы используем его только когда требуется строгая иерархия ролей и аудит доступа.

Последствия неправильного моделирования контента

Моделирование контента — критичный этап. Ошибка на этом этапе стоит дорого. Типичная проблема: поле body типа rich text для всего. Через полгода контент-менеджер хочет вставить видео между абзацами, добавить pull quote с кастомным стилем, встроить интерактивную таблицу. Rich text это не позволяет. Решение — Portable Text (Sanity) или кастомные компоненты в Strapi/Directus через Dynamic Zone. Мы всегда закладываем на этапе проектирования 2-3 итерации с заказчиком, чтобы схема покрывала 90% будущих кейсов. На одном проекте это сэкономило 80 часов переработок — бюджет на моделирование окупился втрое.

Как мы строим проекты на headless CMS

Фронтенд под headless CMS практически всегда идёт на Next.js (App Router) или Nuxt. Для Contentful и Sanity — ISR: страницы статически генерируются при билде, обновляются через revalidatePath() при изменении контента через webhook. Для Strapi/Directus с частым обновлением данных — SSR с cache: 'no-store' или SWR на клиенте.

Кейс: редизайн корпоративного сайта производственной компании. Предыдущий сайт — WordPress с ACF, 200+ страниц, 4 языка. Проблемы: TTFB 3,8 с, редакторы жаловались на медленный админ.
Перешли на Strapi (self-hosted, PostgreSQL), Next.js App Router. Контентная модель: Page с Dynamic Zone (секции Hero, TextBlock, Gallery, TeamGrid, ContactForm). Локализация через Strapi i18n plugin + next-intl на фронтенде. Деплой фронтенда на Vercel с ISR, ревалидация через Strapi webhook на entry.publish.

TTFB с 3,8 с упал до 180 мс (статика с CDN) — разница в 21 раз. Редакторы получили чистый интерфейс без 47 плагинов. Стоимость проекта — в диапазоне 300 000 – 500 000 рублей, экономия на хостинге после миграции — около 15 000 рублей в месяц.

Для понимания headless CMS и TTFB — рекомендую базовые статьи.

Процесс внедрения разбит на этапы:

1. Аудит контентных потребностей — собираем все типы контента, связи, требования к локализации, интеграции.
2. Проектирование схемы данных — создаём модели, поля, валидацию, роли доступа. Документируем в Swagger/OpenAPI.
3. Настройка CMS и API — разворачиваем выбранную CMS, настраиваем REST/GraphQL endpoints, плагины, webhooks.
4. Разработка фронтенда — подключаем Next.js/Nuxt, настраиваем ISR/SSR, компоненты секций, роутинг.
5. Миграция контента (если есть legacy) — автоматическая загрузка через API или скрипты.
6. Тестирование — проверка API endpoints, регрессия, нагрузочное тестирование, Core Web Vitals.
7. Деплой — настройка CDN, SSL, CI/CD, мониторинг.

Сколько времени занимает внедрение?

Стандартный путь включает все этапы. Миграция с WordPress на headless CMS занимает столько же времени, сколько сам проект — часто больше. Особенно если в WordPress накоплены кастомные поля через ACF с нестандартной структурой. Наши средние сроки:

Стоимость рассчитывается индивидуально после брифа. Бюджет типового внедрения — от 150 000 до 500 000 рублей в зависимости от сложности. Экономия на хостинге за счёт статической генерации — до 40% в месяц.

Что входит в работу

• Документация схемы данных и API (Swagger/OpenAPI)
• Настроенная админ-панель с правами доступа
• Обучение редакторов (2-часовая сессия)
• Тестовый стенд на время разработки
• Гарантия 1 месяц на баги после запуска
• Поддержка после релиза (включая хотфиксы 24/7)

Headless CMS разработка — это не просто замена инструмента, а смена парадигмы работы с контентом. Мы помогаем сделать этот переход без простоев и потери данных. Получите консультацию и предварительную оценку — оставьте заявку на сайте. Закажите внедрение headless CMS с гарантией результата.