---
title: "Pollora: WordPress усередині Laravel-застосунку"
url: https://laravelukraine.com/blog/pollora-wordpress-useredini-laravel-zastosunku
date: 2026-10-30
---

# Pollora: WordPress усередині Laravel-застосунку

[Pollora](https://pollora.dev) - фреймворк, який запускає WordPress усередині Laravel-застосунку. Laravel стартує першим і обробляє фронтенд-запити своїм маршрутизатором, контролерами й Blade, а адмінка WordPress, його база й плагіни працюють як на звичайному сайті. Проєкт на цьому тижні [розібрали на Laravel News](https://laravel-news.com/pollora-wordpress-laravel), і він зачіпає знайому багатьом студіям ситуацію: клієнти сидять у WordPress, а команда пише на Laravel.

Досі тут було два шляхи. Або писати тему з `functions.php`, де реєстрація post types і хуків розмазана по викликах функцій, або тримати окремий Laravel-застосунок і читати таблиці WordPress збоку. Pollora пропонує третій: клієнт лишається у звичній адмінці, а код пишеться по-ларавелівськи.

### Як це влаштовано

Проєкт - це Laravel-застосунок: `public/index.php` є фронт-контролером Laravel, і `routes/web.php` перевіряється першим. Composer ставить ядро WordPress у `public/cms`, а `wp-content` лежить у `public/content` - структура в дусі Bedrock. Pollora завантажує WordPress під час старту Laravel, з конфігурацією й підключенням до бази даних Laravel.

WordPress, як і раніше, розбирає кожен запит, тому умовні теги на кшталт `is_single()` працюють. Але відповідь рендерить уже Laravel.

Новий проєкт створюється через Composer або [Pollora CLI](https://pollora.dev/getting-started/installation/), який вміє ще й підняти середовище в DDEV:

```bash
  composer create-project pollora/pollora my-project

  # або
  composer global require pollora/cli
  pollora new my-project --ddev
```

Після встановлення залежностей запускається інтерактивне налаштування: `.env` з доступами до бази, потім установлення WordPress з назвою сайту, мовою й адміністратором. Обидва кроки можна повторити вручну командами `php artisan pollora:env:setup` і `php artisan pollora:install`, а для CI в `pollora:install` усе передається опціями.

### Маршрути на умовних тегах WordPress

Pollora додає до маршрутизатора `Route::wp()` і `Route::wpMatch()`. Вони зіставляють запит з умовним тегом WordPress - `is_page()`, `is_single()` тощо, - причому можна писати і назву функції, і коротку форму на кшталт `page`:

```php
  use App\Http\Controllers\FormController;
  use App\Models\Feature;
  use Illuminate\Support\Facades\Route;

  Route::wp('single', function () {
      return view('post');
  });

  Route::wp('template', 'landing', function () {
      return view('page.landing', [
          'features' => Feature::all(),
      ]);
  });

  Route::wpMatch(['GET', 'POST'], 'page', ['contact', 'request-a-quote'], [FormController::class, 'index']);
```

Описувати маршрут для кожної сторінки не треба. Якщо жоден не підійшов, Pollora йде ієрархією шаблонів WordPress і рендерить відповідне Blade-представлення: сторінка «About» візьме `page-about.blade.php`, а якщо його немає - `page.blade.php`.

### Post types, хуки і REST - атрибутами

Замість `register_post_type()` у `functions.php` post type оголошується класом. Pollora знаходить його сам і генерує slug та підписи з назви класу:

```php
  namespace App\Cms\PostTypes;

  use Pollora\Attributes\PostType;
  use Pollora\Attributes\PostType\HasArchive;
  use Pollora\Attributes\PostType\MenuIcon;
  use Pollora\Attributes\PostType\PubliclyQueryable;
  use Pollora\Attributes\PostType\Supports;

  #[PostType]
  #[PubliclyQueryable]
  #[HasArchive]
  #[Supports(['title', 'editor', 'thumbnail'])]
  #[MenuIcon('dashicons-calendar')]
  class Event
  {
  }
```

Так само працюють actions і filters, причому один метод може слухати кілька хуків:

```php
  #[Action('init', priority: 10)]
  #[Action('wp_loaded', priority: 15)]
  public function setup(): void
  {
      // ...
  }

  #[Filter('the_content', priority: 10)]
  public function filterContent(string $content): string
  {
      return str_replace('ugly', 'shiny', $content);
  }
```

Атрибутами оголошуються й таксономії (`#[Taxonomy]`), REST-маршрути (`#[WpRestRoute]`), задачі за розкладом (`#[Schedule]`), а також команди WP-CLI та AJAX-обробники. Заготовки класів генерують Artisan-команди на кшталт `pollora:make:post-type` і `pollora:make:action`.

### Blade, блоки, медіа й Eloquent

- **Теми** - Blade-шаблони з [Sage Directives](https://log1x.github.io/sage-directives-docs/) (`@posts`, `@title`, `@content`), Tailwind CSS і Vite через `@roots/vite-plugin`. Підтримуються батьківські й дочірні теми.
- **Gutenberg-блоки** створює `php artisan pollora:make:block hero-banner --theme`: `block.json`, JSX-файли для редактора і Blade-шаблон. Шаблон рендерить блок на кожен запит, тож зміна розмітки одразу оновлює всі сторінки з ним, а прев'ю в редакторі береться з того самого шаблону.
- **Медіатека** переїжджає на будь-який диск з `config/filesystems.php` - S3, R2, MinIO - двома змінними `MEDIA_DISK` і `MEDIA_URL`. WordPress далі користується своїми функціями завантаження, тому ACF і WooCommerce працюють без змін. Розміри зображень оголошуються в PHP через `ImageSize` і генеруються на вимогу.
- **Дані WordPress** доступні через Eloquent-моделі `Pollora\Models\Post`, `Page`, `Term`, `User` та інші. Вони побудовані на [Colt](https://github.com/Pollora/colt) - форку Corcel, тож запити в стилі Corcel теж працюють.
- **Для AI-агентів** є пакет Nectar: настанови, навички агентів і MCP-інструменти для Pollora поверх Laravel Boost.

### Чим відрізняється від Acorn, Sage і Corcel

На сайті проєкту є [чесне порівняння](https://pollora.dev/compare/) з інструментами, які вже поєднують Laravel і WordPress. Головна різниця - порядок старту:

- **Acorn** - пакет, який приносить компоненти Laravel у WordPress. WordPress стартує першим, Acorn запускається з теми чи плагіна. Підходить, щоб додати Laravel в наявний сайт без зміни структури.
- **Sage** - стартова тема з Blade, Tailwind CSS і Vite для звичайного WordPress. Якщо потрібна лише тема, автори Pollora самі радять Sage як простіший вибір.
- **Radicle** - найближчий аналог від команди Roots: готовий проєкт з Acorn, Bedrock і Sage, але платний (80 доларів за один сайт, 240 - без обмежень), і WordPress там знову стартує першим.
- **Corcel** - не фреймворк, а набір Eloquent-моделей над таблицями WordPress. Сам WordPress не завантажується: ні хуків, ні плагінів. Добрий вибір, коли WordPress - лише бек-офіс для редакторів, а сайт повністю ваш.

Pollora - це протилежна схема: Laravel-застосунок, у якому живе WordPress. Порівняння відкрито визнає й борг перед Roots: Pollora використовує Bedrock-структуру, `@roots/vite-plugin` і Sage Directives.

### Вимоги й стан проєкту

- PHP 8.4+ - не через сам фреймворк, а через Symfony 8 у `composer.lock` скелета;
- Composer 2, Node.js і npm для збірки ассетів;
- MySQL 5.7+ або MariaDB 10.3+. [Документація](https://pollora.dev/getting-started/installation/) прямо каже, що WordPress завантажується лише з драйвером `mysql`, а SQLite не підтримується, хоча README скелета SQLite ще згадує - орієнтуйтеся на документацію;
- WordPress 7.1+, який Composer ставить сам.

Версії Pollora йдуть за випусками Laravel: останній випуск [pollora/framework](https://github.com/Pollora/framework) - v13.39.1 від 29 жовтня, і пакет залежить від компонентів Laravel 13.39. Ліцензія - MIT, проєкт безкоштовний, розробляє його RuBee group. У власному порівнянні автори називають Pollora молодим проєктом, тоді як в Acorn - близько 2,66 млн установок на Packagist.

### Чи варто братися

Компроміси тут архітектурні, і їх варто зважити заздалегідь:

- **Кожен вебзапит завантажує WordPress і всі його плагіни.** Laravel-маршрут, який до WordPress жодного стосунку не має, однаково платить за старт ядра й плагінів. На сайті з двома десятками важких плагінів це відчутно.
- **Ядро WordPress оновлюється лише через Composer.** Кнопка «Оновити» в адмінці більше не ваш інструмент - оновлення йде через деплой. Для команди з CI це скоріше плюс, для клієнта, який звик оновлювати все сам, - зміна процесу, яку треба проговорити.
- **Теми WordPress як такі зникають.** Фронтенд повністю переходить до Laravel, тож тема з маркетплейсу тут не допоможе.
- **Молодий проєкт.** Випуски виходять часто, і в журналі змін трапляються вимоги переглянути власний код - як-от перехід на Colt 11 у v13.39.1, після якого моделі, що перевизначають методи Colt, мають мати сумісні типи повернення.

Кому це підходить: студіям, які регулярно роблять клієнтські сайти на WordPress і хочуть писати їх з маршрутами, контролерами, чергами й тестами Laravel. Почати варто з невеликого нового проєкту, а не з міграції живого сайту: окремого посібника з переходу із Sage чи Acorn поки немає, хоча Blade-шаблони, Sage Directives і Vite-збірка переносяться майже без змін.