Forem: hamed pakdaman

What 183 admin pages look like — building a full Laravel CMS in 2026

hamed pakdaman — Sat, 09 May 2026 13:51:47 +0000

A year ago I started building a CMS because I had three options for client work and none fit:

WordPress — works, but 250+ plugin CVEs/week (Patchstack 2024). I patch sites every week. Tired of it.
Contentful / Sanity — modern, but $300/mo entry pricing for SMB use cases. Vendor lock is real.
Strapi / Payload — solid, but Node-only. I'm a PHP/Laravel shop.

So I built UnfoldCMS — a self-hosted Laravel CMS that ships as a single product, not a framework you assemble. This post is a tour of what's actually in there. Not the marketing version — the "here are the 183 admin pages" version.

If you're picking a CMS in 2026, this is the kind of breakdown I wish vendors actually published.

The stack, briefly

Laravel 11 + Inertia 2 + React 19 + TypeScript
Tailwind v4 + shadcn/ui (50+ components)
MySQL / MariaDB
Spatie Media Library, Spatie Permission (RBAC), Spatie Activity Log
Runs on $5/mo Hetzner VPS at ~80MB RAM idle

The shadcn + Tailwind theming side I covered in my previous post. This post is about the CMS surface — the modules, the editor, the publishing pipeline.

What's in the box

Every module here is built-in. No "plugin marketplace" — Laravel has service providers, that's the extension model.

Posts and Pages

The core publishing primitives. Both share the same model (Post with a content_type enum), but render differently.

Posts = blog entries, indexed under /blog/{slug}, listed on the blog index page.
Pages = root-level content like /about, /pricing, /migrate-from-wordpress.
Same editor, same media handling, same SEO fields. Only the URL routing differs.

The editor is a structured block editor built on Tiptap's foundation. Each block is a discrete field — heading, paragraph, image, code block, callout, table — not a free-form blob. Editors get predictable layouts; developers get clean data to query.

Scheduled publishing is built in. posted_at in the future + is_published = true = post appears at the scheduled time. A single Laravel scheduler entry runs every minute and flips visibility.

Media Library

Spatie Media Library under the hood. Three things made it worth using over a custom solution:

Polymorphic associations — any model can have media (posts, users, settings, custom models).
Conversions on demand — define large, medium, thumbnail once; conversions generate when first requested.
Featured-image collections — separate featured-image collection per post, separate from inline body images.

The trap I'd warn against: the legacy image_large text column on the post table looks tempting for "set the hero image." Don't. Use Spatie collections — the template renders them automatically with proper aspect ratio handling.

Menus

Tree-based menu builder. Drag-and-drop reorder. Each menu item links to internal routes (resolved via Laravel's named routes), external URLs, or content (auto-generates the URL from the slug).

Multiple menus per site — Header, Footer, Mobile, Sidebar — and they support nested children. The frontend templates pull menus by slug:

$mainMenu = Menu::bySlug('main');

Forms

A form builder with a JSON schema. Fields, validation rules, success/error messages, redirect targets — all configurable from the admin. Submissions go to a form_submissions table; admins see a list with filters, can export to CSV, and forward to email or webhooks.

The architecture choice: forms are a CMS feature, not a separate app. They share the auth, the rate limits, the spam filtering (Spatie honeypot), and the activity log with the rest of the system.

Settings

Key-value store with a config-driven schema. The schema lives in config/site.php — defaults set once, admin UI generates from the schema, frontend reads via Setting::get('key', $fallback).

Why this matters: if a customer wants a "show announcement banner" toggle, you don't write a migration, a form, a controller, and a Blade variable. You add a key to the schema and it shows up in the admin automatically.

Theming

Three themes ship — Default (blue), Purple, Unfold (soft purple). Switching is one CSS variable swap (covered in detail in the previous post). The theming primitive is data-theme="..." on the root element + Tailwind v4's @theme directive.

What's in scope for theming: colors, radius, font stack. Not in scope: layout, spacing, component shape. That's intentional — themes are visual, not structural.

Templates

Above themes is templates — full frontend designs that ship with the CMS. The active one on this site is "Aurora," which has its own seed data, blade templates, and section components. Templates are swappable at install time; runtime swap is harder because each ships its own homepage section data.

SEO

Built on the ralphjsmit/laravel-seo package, extended with site-wide defaults and per-post overrides.

What gets generated automatically:

<title> and meta description (with explicit override fields)
Open Graph + Twitter card tags
JSON-LD schema: Article, BreadcrumbList, Organization
Canonical URLs with proper trailing-slash handling
hreflang tags for multi-language sites

The CMS fallback for SEO title is the post title — but it title-cases it, which corrupts proper nouns ("WordPress" → "Wordpress"). Lesson learned the hard way: always set seo_title and meta_desc explicitly, never rely on the fallback. There's now a hard rule in our content-publishing skill.

RBAC

Spatie Permission. Three default roles ship — Super Admin, Editor, Author — and you can add more from the admin. Permissions are granular (per-model + per-action), not just role-based.

The middleware story is straight Laravel:

Route::middleware(['auth', 'role:editor|admin'])->group(function () {
    Route::resource('posts', PostController::class);
});

No vendor magic. If you've used Spatie Permission, you know exactly what's happening.

Multi-language

spatie/laravel-translatable. Each translatable field (title, body, seo_title, meta_desc) stores a JSON map of {locale: value}. The admin shows a locale switcher; the frontend resolves based on URL prefix (/fr/about) or domain.

What's not in there yet: automatic translation (machine translation pipeline). Editors translate manually for now.

The publishing pipeline (the part that took the longest)

Building a "save post" button is a weekend. Building a publishing pipeline that handles drafts, scheduled publishes, sitemap regeneration, cache invalidation, and SEO updates without race conditions is a year.

What's behind a publish action:

Validation — required fields, slug uniqueness, meta-desc length
Markdown → HTML conversion (server-side; the body is stored as HTML so the template just renders it raw)
SEO record sync — seo_title, meta_desc, og_image written to a related table
Spatie media attachment — featured image moves from temp upload to permanent collection
Sitemap regeneration — php artisan sitemap:generate runs synchronously (no queue worker required for shared hosting)
Cache invalidation — view:clear, route:clear, edge cache purge if configured
Activity log — Spatie ActivityLog records who published what

All of this runs synchronously in the request because the CMS targets shared hosting where queue workers aren't a given. If you're on a real VPS, you can flip QUEUE_CONNECTION=database and it queues automatically. The synchronous fallback is what makes "deploy to a $5 VPS" actually work.

Deployment story

Single artisan command: php artisan deploy. It does:

Verifies clean working tree on the deploy branch
Pushes to git
Pulls on the server
Runs composer install --no-dev (skipped if composer.lock unchanged)
Runs php artisan migrate --force
Builds frontend assets locally with pnpm run build, syncs to server via rsync (skipped if no JS/CSS changed)
Clears config/view/route caches
Verifies HTTP 200

The lessons embedded in this command:

Frontend builds locally, not on the server. Faster, and avoids needing Node on the server.
Composer skip when lockfile unchanged saves ~30s per deploy.
Rsync over SCP for assets — incremental, only uploads changed files.
HTTP 200 verification at the end catches deploys that broke the site silently.

I've shipped enough Laravel apps that I now consider the deploy command part of the product, not a project.

What's not in the box (yet)

Honest list:

Public headless API

Internal REST works. Public endpoints + signed webhooks ship late 2026. Until then, if you want to use UnfoldCMS as a content backend for a Next.js site, you write a thin Laravel route that returns JSON:

Route::get('/api/blog/{slug}', function (string $slug) {
    return Post::published()->whereSlug($slug)->firstOrFail();
});

Three lines, but I get it — that's not the same as a polished public API. Late 2026.

Plugin marketplace

Not building one. Extension model is Laravel service providers + middleware. If you know Laravel, you know how to extend it. If you don't, the learning curve is "Laravel itself," which is a real cost but a transferable one.

Visual page builder

The block editor handles structured content well. It's not a Webflow-style drag-and-drop layout designer, and probably won't be — different category. If you need that, Webflow or Storyblok is the right tool.

Multi-site / multi-tenant

Single site per install today. Agencies running 20 client sites run 20 installs (cheap on Hetzner — $5 × 20 = $100/mo for hosting; the license is per-site too).

The numbers

Concrete, not aspirational:

Lines of code: ~80K (PHP) + ~45K (TS/TSX) — a real product, not a toy
Pages in admin: 183
shadcn components: 50+
Themes shipped: 3
Memory footprint: ~80MB idle on Hetzner CX22
Cold start: ~250ms first request, ~40ms after warm
Build time: ~12 seconds (Vite + Inertia bundle)
Tests: ~600 PHPUnit tests, ~80% coverage on the critical paths

Pricing decision

One-time license per site. $99 Solo, $199 Pro, $499 Agency.

The reasoning: subscriptions hold customers' data hostage. A one-time license means a customer can install it, never pay again, and still own the install — code, database, content. If I disappear tomorrow, the install keeps working.

The downside: ARR is harder to project. The upside: customers actually trust me. After two years, I'd pick this model again.

Why I built it (the short version)

WordPress works for some sites. Contentful works for enterprise teams. None of them work for the in-between — small agencies and SMBs running 5–20 sites who want owned data, sane DX, and no monthly bill that scales with their growth.

UnfoldCMS is what I built for that gap. It's not the right answer for everyone — the comparison pages are explicit about who it's for and who it isn't.

Try it

Live demo (admin login on the page): https://unfoldcms.com/demo
Source: https://github.com/hpakdaman/unfoldcms
Docs: https://unfoldcms.com/docs
Comparison vs WordPress / Contentful / Sanity / Payload: https://unfoldcms.com/compare

Honest critique welcome in the comments — that's how the product gets better.

— Hamed

Building a themeable CMS admin with shadcn/ui + Tailwind v4 — lessons from 50+ components

hamed pakdaman — Sat, 09 May 2026 13:29:05 +0000

I shipped a Laravel CMS where the entire admin is built on shadcn/ui — 50+ components, 183 pages, three themes, runtime switching with no build step. Here are the five things that mattered most.

Why shadcn over Material UI / Ant Design

The deciding factor: shadcn components are my code. When I need to change a Button variant or extend DataTable, I edit the file. No npm overrides, no className wars, no vendor PR queue.

Tradeoff: when shadcn upstream ships a new pattern, I port it manually. Budget ~1 day/quarter for upgrades.

Lesson 1: Layout primitives save 100 pages of CSS

Three components used everywhere — PageContainer, Card, Stack. The PageContainer alone replaced ~40 page-level layout decisions. Three good ones beats 10 flexible ones.

Lesson 2: Tailwind v4 + CSS variables = themes without a build

@theme {
  --color-primary: oklch(0.55 0.27 262);
}
[data-theme="purple"] {
  --color-primary: oklch(0.55 0.27 304);
}

Switching themes:

document.documentElement.dataset.theme = 'purple';

No bundle changes. No re-render. CSS variables flip and every shadcn component updates because they reference the variable, not a hardcoded color. I expected theming to be the hard part — it took an afternoon.

Lesson 3: One Sidebar component, different data

shadcn's Sidebar is flexible enough to handle admin nav and docs nav with the same component. Data varies per-page; the component is shared. This is what makes a 183-page admin feel like one app.

Lesson 4: DataTable is the most underrated shadcn component

Every list view — Posts, Pages, Media, Users, Forms — uses the same DataTable wrapper. Server-side pagination, sorting, row selection, bulk actions, search. The columns array is the only per-page logic.

Lesson 5: TypeScript strictness is non-negotiable

shadcn ships excellent types. Don't loosen them. Every page-level component declares its props type explicitly, even when "obvious."

What didn't work

Tiptap as the rich-text editor. Great for free text, wrong for structured fields. Rebuilt on Tiptap's foundation with a custom block model — 3 weeks I'd have skipped with better evaluation.
Copying all 50 shadcn components up front. Only 30 actually got used. Copy on demand.
Tailwind v3 → v4 mid-build. ~4 hours of breaking changes. Start on v4 today.

What I'd use shadcn for again

Anything that needs custom design
Long-lived products where the maintenance cost is justified
Type-safe fullstack apps

What I wouldn't use it for: throwaway prototypes (use Mantine), marketing sites (Tailwind alone is faster).

Source: https://github.com/hpakdaman/unfoldcms
Live demo: https://unfoldcms.com/demo

I'm Hamed — built UnfoldCMS because none of WordPress, Contentful, or Strapi/Payload fit my Laravel shop. Honest critique welcome.

What frustrates you most about your current CMS?

hamed pakdaman — Tue, 21 Apr 2026 06:55:28 +0000

Hey developers! 👋
I'm working on improving a Laravel-based CMS and want to understand what actually matters to developers when choosing/using a CMS.

Quick question

What's your biggest frustration with your current CMS (WordPress, Strapi, Contentful, etc.)?
Is it:

Performance/bloat?
Poor developer experience?
Expensive pricing?
Difficult customization?
Security concerns?
Something else entirely?

Bonus: What CMS are you currently using and why haven't you switched?

Not trying to sell anything—genuinely trying to understand what sucks and what doesn't. Your honest feedback helps build better tools for all of us 🙏

MultiCarbon: Native Jalali & Hijri Calendar Support for PHP Carbon

hamed pakdaman — Sat, 14 Feb 2026 14:38:53 +0000

If you've ever worked on a project targeting users in Iran, Afghanistan, or Arabic-speaking countries, you know the pain of converting dates between Jalali (Solar Hijri), Hijri
(Islamic Lunar), and Gregorian calendars.

I built MultiCarbon to solve this once and for all — not as a wrapper, but as a direct extension of nesbot/carbon. Every Carbon method you already know works seamlessly in any
calendar mode.

## Install

  composer require hpakdaman/multicarbon

Requires PHP 8.1+ and Carbon 3.

The Basics — One Timestamp, Three Calendars

The core idea is simple: the underlying timestamp never changes. You just switch the presentation layer.

use MultiCarbon\MultiCarbon;

$date = new MultiCarbon('2025-03-21');

echo $date->jalali()->format('l j F Y');
// جمعه 1 فروردین 1404

echo $date->hijri()->format('l j F Y');
// الجمعة 21 رمضان 1446

echo $date->gregorian()->format('l j F Y');
// Friday 21 March 2025

That's it. Same object, three calendars, fully fluent.

Create Dates Directly in Any Calendar

No need to mentally convert. Just think in the calendar you need:

// Nowruz (Persian New Year)
$nowruz = MultiCarbon::createJalali(1404, 1, 1);
echo $nowruz->gregorian()->format('Y-m-d'); // 2025-03-21

// First day of Ramadan
$ramadan = MultiCarbon::createHijri(1446, 9, 1);
echo $ramadan->gregorian()->format('Y-m-d'); // 2025-03-01

Calendar-Aware Arithmetic

This is where it gets interesting. Adding a month in Jalali isn't the same as adding a month in Gregorian — month lengths differ. MultiCarbon handles this automatically:

// Shahrivar has 31 days, Mehr has 30
$date = MultiCarbon::createJalali(1404, 6, 31);
$date->addMonth();
echo $date->format('Y/m/d'); // 1404/07/30 — clamped to Mehr's max

// Leap year handling
$date = MultiCarbon::createJalali(1403, 12, 30); // Esfand 30 (1403 is leap)
$date->addYear();
echo $date->format('Y/m/d'); // 1404/12/29 — clamped (1404 is not leap)

Localized Names — Persian & Arabic

Month names, weekday names, and even AM/PM are fully localized:

$date = MultiCarbon::createJalali(1404, 3, 15);

echo $date->jalali()->monthName; // خرداد
echo $date->jalali()->dayName; // پنجشنبه

echo $date->hijri()->monthName; // ذیحجه
echo $date->hijri()->dayName; // الخمیس

Farsi, Arabic & Latin Digits

Switch the digit system globally with one line:

MultiCarbon::setDigitsType(MultiCarbon::DIGITS_FARSI);
echo MultiCarbon::createJalali(1404, 1, 1)->format('Y/m/d');
// ۱۴۰۴/۰۱/۰۱

MultiCarbon::setDigitsType(MultiCarbon::DIGITS_ARABIC);
echo MultiCarbon::createHijri(1446, 9, 1)->format('Y/m/d');
// ١٤٤٦/٠٩/٠١

MultiCarbon::setDigitsType(MultiCarbon::DIGITS_LATIN); // reset

diffForHumans() in Persian & Arabic

echo MultiCarbon::createJalali(1403, 1, 1)->diffForHumans();
// 1 سال پیش

echo MultiCarbon::createHijri(1445, 1, 1)->diffForHumans();
// منذ 1 سنة

Calendar-Aware Boundaries

Start/end of month and year respect the active calendar:

$date = MultiCarbon::createJalali(1404, 6, 15, 14, 30, 0);

echo $date->copy()->startOfMonth()->format('Y/m/d H:i:s');
// 1404/06/01 00:00:00

echo $date->copy()->endOfMonth()->format('Y/m/d H:i:s');
// 1404/06/31 23:59:59

echo $date->copy()->endOfYear()->format('Y/m/d H:i:s');
// 1404/12/29 23:59:59 (not leap)

Leap Year Detection

MultiCarbon::createJalali(1403, 1, 1)->isLeapYear(); // true
MultiCarbon::createJalali(1404, 1, 1)->isLeapYear(); // false

Comparisons & Diff

All comparison methods work in the active calendar:

$a = MultiCarbon::createJalali(1404, 1, 1);
$b = MultiCarbon::createJalali(1404, 1, 25);

$a->isSameMonth($b); // true
$a->isSameDay($b); // false
$a->lessThan($b); // true
$a->diffInDays($b); // 24

Convert from Carbon

Already using Carbon in your project? Convert seamlessly:

$carbon = \Carbon\Carbon::parse('2025-03-21');
$mc = MultiCarbon::fromCarbon($carbon);

echo $mc->jalali()->format('Y/m/d'); // 1404/01/01
echo $mc->hijri()->format('Y/m/d'); // 1446/09/21

Calendar Properties

Access all date components in the active calendar:

$date = MultiCarbon::createJalali(1404, 6, 15);

$date->year; // 1404
$date->month; // 6
$date->day; // 15
$date->dayOfYear; // 170
$date->daysInMonth; // 31
$date->quarter; // 2
$date->weekOfYear; // 36
$date->isWeekend(); // false (Iranian week: Fri is weekend)

Serialization

$date = MultiCarbon::createJalali(1404, 7, 10, 8, 30, 0);

$date->toDateString(); // "1404-07-10"
$date->toArray();
// ['year' => 1404, 'month' => 7, 'day' => 10, 'hour' => 8, 'minute' => 30, 'second' => 0]

echo $date; // "1404/07/10 08:30:00"

Laravel Integration

MultiCarbon ships with a Laravel service provider, facade, and Blade directives out of the box:

// Global helpers
jdate('Y/m/d H:i:s'); // Current Jalali date
hdate('Y/m/d'); // Current Hijri date

// Blade directives
@jdate('Y/m/d H:i:s') // Current Jalali
@hdate('Y/m/d') // Current Hijri
@jalali($user->created_at, 'Y/m/d') // Convert to Jalali
@hijri($post->published_at, 'Y/m/d') // Convert to Hijri

How It Works Under the Hood

MultiCarbon uses debug_backtrace() to detect whether a property or method is accessed by your code or by Carbon's internal engine. This means:

When you call $date->year → returns the Jalali/Hijri year
When Carbon internally calls $this->year → returns Gregorian so parent logic doesn't break

Links:

GitHub: https://github.com/hpakdaman/multicarbon
Packagist: https://packagist.org/packages/hpakdaman/multicarbon

I'd love to hear your feedback, suggestions, or feature requests. Feel free to open an issue or drop a comment below!