16 — Roadmap and phases#

Six phases. One at a time. A phase is finished when its exit criteria pass and php artisan test is green — not when the code is written.

At the start of a phase: a short plan. At the end: a summary under 15 lines in simple English saying what was built, exactly how to try it in the browser (URLs and clicks), and how to deploy it to cPanel.

Phase 0 — Project setup#

Build

• Fresh Laravel 11 project, PHP 8.3. Install livewire/livewire 3, intervention/image, spatie/laravel-permission, Laravel Breeze (Blade, login only). Vite: Alpine.js, SortableJS, TipTap.
• Admin shell: layout with the 7 sidebar items (empty screens are fine), top bar, user menu, toast system, in-app modal component. No browser dialogs anywhere, from the first commit.
• lang/bn and lang/en with the file set from 12, plus the key-parity test.
• Self-hosted Noto Sans Bengali / Noto Serif Bengali / Inter with unicode-range and swap.
• All migrations from 03-database-schema.md, in the stated order, including the deferred-foreign-key migration. Models with relationships, casts, scopes (SiteScope), and factories.
• Seeders: roles + permissions, default theme tokens, 5 starter page templates, demo content.
• php artisan kodepress:install per 14.3, with the cms:install alias.
• kodepress:doctor with the checks from 11.9.
• Catch-all public route resolving by site + locale + path, with a designed 404.
• config/kodepress.php.

Exit criteria

• kodepress:install runs on an empty database and prints Done. Open /admin.
• Login works; the four roles and the full permission list exist.
• Every table in doc 03 exists with the stated indexes and foreign keys (a schema test asserts the table and column names).
• The admin shell renders in bn and en with no missing keys.
• Tests: install on empty DB, idempotent re-run, login, roles exist, key parity, 404 renders.

Phase 1 — Core page builder#

Build

• BlockRegistry, SchemaValidator, Sanitizer, PageRenderer, and the 10 basic blocks: Heading, Text, Image, Button, Video, Gallery, Form (stub), Post List (stub), Accordion, HTML (Admin only). Plus Spacer and Divider, which the section gallery needs.
• The Livewire editor per 05-page-builder.md: outline tree, preview iframe, generated settings panel (Content tab only by default), Add Section gallery with the 8 ready-made sections, drag and drop, duplicate, delete, undo/redo, autosave, device preview, Publish.
• Pages screen: list, search, status filter, create from template, duplicate, trash, restore.
• Media library per 10.1: drag-drop upload, folders, search, compression, WebP, variants, alt text; openable from any image field.
• Publish pipeline: version row, render, write the HTML cache, serve cached HTML publicly.
• HtmlCache + CacheInvalidator with page-level invalidation.

Exit criteria

• A new user creates and publishes a page in 10 clicks or fewer from a template.
• The public URL serves the published content from the cache; the second request makes zero queries.
• Editing and republishing clears only that page.
• A block added as a new folder appears in the palette with no admin-code change (asserted by a test that creates a temporary block folder).
• Tests: create from template, edit a block, publish, public content, cache clear, upload and WebP conversion, php upload rejected, HTML block denied to a non-Admin.

Phase 2 — Content features#

Build

• Blog: type = post in the same editor, with the Post tab (excerpt, featured image, author, categories, tags). Nestable categories, flat tags with inline creation, scheduled publishing via the single cron entry. The real post_list block with filters, layouts and pagination.
• Public blog surfaces: post, category (nested paths), tag, author, search, RSS.
• Design -> Theme per 09-theme-tokens.md: tokens, 4 presets, contrast guard, TokenCompiler writing one hashed CSS file.
• Templates gallery: save a page or section as a template with a thumbnail; use templates when adding pages and sections.
• Version history: list, structural compare, one-click restore into the draft, retention prune.
• Per-page SEO, sitemap.xml, robots.txt, redirect manager with automatic 301 on slug change.

Exit criteria

• A scheduled post publishes on the cron tick and clears the right cache entries.
• Changing one theme token changes the whole site and busts the stylesheet hash.
• Restoring a version does not publish; publishing it creates a new version.
• A slug change 301s the old URL, including for descendants.
• sitemap.xml excludes noindex and includes archives.
• Tests: scheduling, restore, redirects, sitemap, theme invalidation, nested category archive, Bengali search, RSS validity.

Phase 3 — Navigation and layout parts#

The phase with the most user-visible leverage, and the one most likely to be got wrong. Specs: 07-navigation-megamenu.md and 08-header-footer.md.

Build

• Menu manager: multiple menus, locations, 3-level drag-and-drop tree, bulk operations, live preview, all item types, per-item settings, visibility rules, auto-sync and broken-link flags, active-item highlighting, auto_children, import/export/copy.
• Mega menus: the toggle, the panel editor in the mega context, the 5 ready-made layouts, panel settings, hover/click behaviour with intent delays, keyboard support, the mobile accordion/drawer transformation, storage in menu_items.mega.
• Header and footer as template_parts: three header zones, 6 presets, the header block set, behaviour settings (sticky, shrink, scroll background, hide-on-scroll, height, shadow, border), separate mobile design, footer with 1–6 columns and a bottom bar with {{year}}, footer style settings.
• Multiple named parts with condition-based assignment, the specificity resolver, per-page override, drafts, preview-on-any-page, publish and version restore.
• Site-wide cache clear on any menu, part, theme or site-option change.
• Policies: Editors edit menu items; only Designer and Admin edit parts and mega layouts.

Exit criteria

• A non-technical user builds a header with a mega menu and a 4-column footer in 15 minutes.
• The resolver picks the right part for every rule combination, with the per-page override winning.
• A mega panel renders as a panel on desktop and an accordion on mobile from one tree.
• Renaming a page updates unedited menu labels; deleting a target flags the item and drops it publicly.
• Tests: the two lists in docs 07 and 08, in full.

Phase 4 — Simplification and control#

Build

• Inline editing on the public site for users with permission: per-section Edit, in-place text editing writing to the draft, an unpublished-changes banner, cache bypass for authenticated users only.
• Form builder per 10.2: field types, conditional fields, settings, email notification, submissions list with read state, CSV export with BOM, honeypot and fill-time check, per-form rate limit, optional captcha. The form block becomes real.
• Global blocks: reusable sections, usage counts, editing one updates every page that uses it (invalidating exactly those pages).
• Roles enforced by Policies end to end; optional approval before publish (Writer -> Editor) with notifications and a change-request note.
• Audit log screen: filters, CSV export, read-only, nightly prune.
• Bilingual public pages (/bn/..., /en/...) with the language switcher block and hreflang.
• Backup and restore: chunked ZIP of a PHP-written SQL dump plus media, resumable, authenticated download, safety backup before restore.
• Optional 2FA for Admin; changeable admin URL.
• Onboarding: a 5-step tour on first login (pick a template, edit text, add a section, publish, view the site), skippable and re-runnable.

Exit criteria

• A Writer cannot publish; approval moves a page through pending and notifies Editors.
• A form submission validates server-side, stores, emails, exports, and resists the bot checks.
• Editing a global block updates every page using it and nothing else.
• Backup survives an interrupted run and restores onto a clean database.
• The tour completes in 5 steps and ends on the published page.
• Tests: permissions sweep, approval flow, form submission paths, backup/restore, inline-edit authorisation, cache bypass correctness.

Phase 5 — Scale#

Build

• Multi-site: one admin, many domains; a site switcher in the top bar; ResolveSite by host; each site with its own pages, menus, parts, theme and media folder. site_id already exists everywhere, so this is scoping, routing and UI — not a schema change.
• Plugin system: a plugin is a folder that may add blocks, routes, admin screens, migrations and translations; enable/disable in Settings; plugins and plugin_migrations tables; a service provider discovered at boot; a documented, narrow API (17-extensibility.md).
• Block pack import/export as a zip, validated and sandboxed on import.
• A sample custom-data-type plugin (property listings) proving the API: a new content type, its admin screens, its blocks and its public routes, written without touching core.

Exit criteria

• Site A can never read site B data — asserted by tests at the model, route and cache layers.
• Disabling a plugin leaves the site renderable: pages using its blocks show a clear placeholder in the editor and render nothing publicly, never a 500.
• The sample plugin installs, enables, works and uninstalls cleanly.
• Tests: site isolation, plugin lifecycle, block-pack import validation, missing-block degradation.

Cross-phase rules#

Out of scope for all phases#

E-commerce, membership, a public content API, a headless front end, a theme marketplace, real-time co-editing, comments. See 01-overview.md.

KodePress documentation · generated from the Markdown sources by tools/build-docs-site.py · internal preview, not indexed.