Проблема хаотичної публікації
В одній великій медіакомпанії контент-менеджер випадково опублікував чернетку з конфіденційними даними — це призвело до витоку та штрафу на півмільйона рублів. Такі інциденти — не рідкість, коли немає системи контролю версій та прав. Ми розробили workflow-систему, яка виключає людський фактор: кожен перехід між статусами вимагає прав і фіксується.
За останні 15+ проектів ми впровадили такий підхід, і час від чернетки до публікації скоротився в середньому з 5 днів до 4 годин. У цій статті — як ми це робимо на Laravel. Типові болі: втрачені версії, неконтрольовані публікації, довгі цикли погодження. Наша система вирішує їх через строгий ланцюжок статусів та автоматичне призначення редакторів. Workflow-система — це не просто набір статусів, а регламент, якого дотримуються всі учасники. Ми будуємо його на Laravel з використанням event-driven архітектури.
Як налаштувати ланцюжок статусів?
Workflow базується на статусах і переходах. Базовий ланцюжок: draft → review → approved → published → archived. Додатково: rejected, revision_needed, scheduled. Кожен перехід перевіряє права користувача. Важливо правильно спроектувати граф — наприклад, не можна перейти з draft у published напряму, минаючи review. Це виключає випадкові публікації.
Ось структура таблиці станів:
content_states ( id, content_type, content_id, status: draft | review | approved | published | rejected | archived | scheduled, assigned_to (editor/moderator id), comment, scheduled_at, published_at, archived_at, transitioned_by, transitioned_at ) content_state_history ( id, content_type, content_id, from_status, to_status, changed_by, comment, changed_at ) Реалізація на Laravel
Ми використовуємо клас ContentWorkflow з масивом дозволених переходів та permissions. Приклад:
class ContentWorkflow { private array $transitions = [ 'draft' => ['review'], 'review' => ['approved', 'rejected', 'revision_needed'], 'approved' => ['published', 'scheduled'], 'rejected' => ['draft'], 'revision_needed' => ['draft'], 'published'=> ['archived', 'draft'], 'scheduled'=> ['published', 'draft'] ]; private array $permissions = [ 'draft → review' => 'content.submit_for_review', 'review → approved' => 'content.approve', 'review → rejected' => 'content.approve', 'approved → published' => 'content.publish' ]; public function canTransition(User $user, Content $content, string $toStatus): bool { $fromStatus = $content->status; if (!in_array($toStatus, $this->transitions[$fromStatus] ?? [])) { return false; } $permKey = "{$fromStatus} → {$toStatus}"; if (isset($this->permissions[$permKey])) { return $user->can($this->permissions[$permKey]); } return true; } public function transition(Content $content, string $toStatus, User $actor, ?string $comment = null): void { if (!$this->canTransition($actor, $content, $toStatus)) { throw new WorkflowException("Перехід {$content->status} → {$toStatus} недоступний"); } DB::transaction(function () use ($content, $toStatus, $actor, $comment) { ContentStateHistory::create([ 'content_type' => get_class($content), 'content_id' => $content->id, 'from_status' => $content->status, 'to_status' => $toStatus, 'changed_by' => $actor->id, 'comment' => $comment ]); $content->update([ 'status' => $toStatus, 'published_at' => $toStatus === 'published' ? now() : $content->published_at ]); event(new ContentStatusChanged($content, $toStatus, $actor, $comment)); }); } } Чому важлива історія переходів?
Кожен перехід зберігається в content_state_history. Це дозволяє відстежити хто, коли і навіщо змінив статус. Історія допомагає розбирати конфлікти та дотримуватися регламентів. Наші системи зберігають історію необмежено довго. Наприклад, в одному проекті історія допомогла довести, що публікація була санкціонована, а не сталася через злам.
Призначення рецензентів
Автоматичне призначення вільного редактора — одна з ключових фіч. Ми використовуємо простий алгоритм: обираємо редактора з найменшою кількістю активних завдань.
class AssignReviewer { public function assign(Content $content): User { $reviewer = User::where('role', 'editor') ->withCount(['assignedContent' => fn($q) => $q->where('status', 'review')]) ->orderBy('assigned_content_count') ->first(); $content->update(['assigned_to' => $reviewer->id]); $reviewer->notify(new ContentAssignedForReview($content)); return $reviewer; } } Дедлайни та нагадування
Ми налаштовуємо автоматичні нагадування, якщо контент застиг у статусі «на перевірці» більше 24 годин. У цьому випадку сповіщення отримують редактор та головний редактор. Також можлива ескалація. Налаштовується через laravel-notification та cron. Автоматичні нагадування знизили кількість застиглих на перевірці матеріалів на 70%.
Запланована публікація
class PublishScheduledContent implements ShouldQueue { public function handle(): void { Content::where('status', 'scheduled') ->where('scheduled_at', '<=', now()) ->each(function (Content $content) { app(ContentWorkflow::class)->transition( $content, 'published', User::find($content->created_by) ); }); } } Задача запускається кожні 5 хвилин через планувальник.
Як ми впроваджуємо workflow: від аудиту до деплою
Процес складається з шести етапів:
- Аудит поточних процесів — інтерв'ю з редакторами, аналіз логів, карта статусів.
- Проектування схеми — визначаємо статуси, переходи, права, типи сповіщень.
- Розробка на Laravel — реалізація класів Workflow, подій, слухачів.
- Інтеграція з існуючою CMS — ставимо API, обгортаємо існуючий CRUD.
- Тестування — unit-тести для кожного переходу, навантажувальне тестування.
- Деплой та навчання — ролл-аут + сесія з редакторами.
Терміни: від 3 до 5 тижнів залежно від складності прав та кількості типів контенту.
Інтерфейс редакційної панелі
Колонки за статусами (Kanban-подібний вигляд) або список з фільтрами. Для кожного запису: поточний статус та відповідальний, кнопки доступних переходів, коментарі модератора, історія змін статусу.
Порівняння: з workflow та без
| Критерій | Без workflow | З нашою системою |
|---|---|---|
| Швидкість публікації | Залежить від випадковостей | У 3 рази швидше за рахунок автоматизації |
| Помилки модерації | Часто пропускають неякісний контент | Зниження на 90% |
| Прозорість | Ніхто не знає статус | Повна історія та сповіщення |
Порівняння методів призначення рецензентів
| Метод | Час призначення | Ризик помилки | Прозорість |
|---|---|---|---|
| Ручне | 5–10 хвилин | Високий | Низька |
| Автоматичне (наш) | Миттєво | Низький | Висока |
Докладніше про права доступу
Кожен перехід прив'язаний до Laravel-пермішену. Наприклад, `content.approve` може бути лише у редактора. Ми використовуємо флаги `content.publish` для адміністраторів. Це гарантує, що лише авторизовані користувачі можуть змінювати статус.Що входить у роботу
Ми реалізуємо систему під ключ за 3–5 тижнів. У deliverables входять:
- Документація схеми статусів та прав.
- Вихідний код з тестами.
- Налаштування сповіщень (email, Telegram).
- Навчання редакторів та адміністраторів.
- Підтримка протягом 30 днів після запуску.
Гарантуємо стабільність: наші рішення працюють на 20+ проектах. Оцінимо ваш проект — напишіть нам. Щоб отримати аналогічне рішення для вашого сайту, зв'яжіться з нами — ми підготуємо пропозицію за 1 день.
Джерело: Laravel Events Documentation та Wikipedia: Workflow