dominservice/laravel-cms

Reusable Laravel CMS for multilingual pages, blocks, categories and media-driven content structures.

What This Package Solves

dominservice/laravel-cms is designed for projects that need a practical CMS layer on top of Laravel, without locking the application into a closed website builder.

It gives you:

• multilingual page and block content models,
• configurable admin sections for content and categories,
• config-driven settings dashboards,
• Media Kit integration for images and video slots,
• publishable views that can be adapted to any admin theme,
• a structure that can start as a company website and grow into a larger CRM, ERP or portal.

Key Features

• multilingual contents and categories,
• nested category trees,
• configurable admin routes, middleware, layout mode and route names,
• block-oriented homepage and static page management via cms.default_pages.*,
• configurable block schemas stored in meta,
• repeater fields for cards, FAQ items and similar structured content,
• Editor.js profile support for rich text fields,
• media slots for desktop/mobile image and video handling,
• direct integration with dominservice/laravel-media-kit, including reusable library assets,
• publishable views and language files.

Requirements

The 5.x package line targets the current DominPress application stack:

• PHP 8.3 or newer,
• Laravel 13.32 or newer,
• Livewire 4.4 or newer,
• kalnoy/nestedset 7.x.

Laravel 9–12 and Livewire 3 remain supported by the previous 4.x package line. They are not supported by 5.x because the current kalnoy/nestedset release requires Illuminate 13.

Installation

Admin Panel

The package includes a configurable admin panel for content, categories and settings.

Main configuration lives in config/cms.php:

• cms.admin.enabled
• cms.admin.prefix
• cms.admin.route_name_prefix
• cms.admin.middleware
• cms.admin.components.*
• cms.admin.layout.mode
• cms.admin.layout.view
• cms.admin.layout.section
• cms.admin.layout.component

Layout integration supports three modes:

• package: use package-provided layout,
• extends: render inside your existing Blade layout,
• component: render inside a Blade component.

This makes it easy to keep package logic inside the package, while styling the UI in the host project through published views.

Applications may replace individual admin Livewire classes without duplicating the package routes. Every configured class must extend Livewire\Component; omitted keys keep the package implementation:

The content and category index classes expose filterMappedItems() as a protected extension hook. A host integration can therefore add allowlisted search and sorting while retaining section resolution, URLs and delete behavior from the package.

Content Types, Blocks and Schemas

The package supports configurable content and category types. You can keep simple arrays in config or point to your own enum classes.

For block-based pages you can define sections in config and assign form fields, media slots and schema fields per section or block.

Typical use cases:

• homepage sections such as hero, about, services, faq, cta,
• static pages with configurable visual variants,
• reusable block types for landing pages and company websites.

Schema Fields in meta

Block-specific configuration is stored in meta, so the host project can render frontend components using its own Blade views and CSS.

The Livewire form renders and validates these fields automatically. Adding a field does not require a migration, controller, Livewire component or another Bootstrap/Tailwind template:

Supported field types are text, textarea, editorjs, url, email, number, date, datetime-local, select, checkbox/boolean/toggle and one-level repeater. A string value is shorthand for a type, for example 'cta_url' => 'url'. Use required, default, placeholder, help, options and rules to customize a field. Explicit rules replace the inferred validation rules.

Non-translatable values are stored directly in Content::meta; translated values are stored under meta._translations.{locale}. This schema layer changes form generation only and does not replace the host project's theme or public Blade components.

Media Integration

The package uses dominservice/laravel-media-kit as the media layer.

Current integration supports:

• desktop and mobile images,
• desktop and mobile video posters,
• image and video slots in CMS forms,
• importing already uploaded assets from the shared media library,
• keeping CMS views publishable, so the host project can replace the UI without changing package logic.

Media Picker Configuration

The package exposes backend support for selecting library asset UUIDs. The host project can publish and extend the form views to provide a custom picker UX.

Editor.js Profiles

The package supports Editor.js configuration profiles so projects can choose a richer or more compact toolset per field.

Example:

Settings Dashboard

The settings dashboard is driven by configuration and can sync UUID-based assignments back into structured config arrays.

Useful for:

• assigning homepage page UUIDs,
• assigning homepage blocks,
• syncing public menu structures,
• storing multilingual meta fields,
• managing config-driven CMS sections without writing extra controllers.

Views and Overrides

The package is meant to be published and themed.

Recommended approach:

• keep routes, controllers, Livewire classes and storage logic in the package,
• publish package views,
• override the views in the host project to match the chosen admin theme.

This keeps the CMS reusable between projects while still allowing tailored UI.

Extensibility

The package is intentionally config-first and open to project-level extension.

You can extend it through:

• your own enum classes for content and category types,
• additional block schemas in app config,
• published views,
• custom frontend renderers,
• custom permissions and middleware on admin routes,
• custom settings panels and sync indexes.

Upgrade Notes

When upgrading existing projects:

• merge new config keys instead of overwriting the whole file,
• republish views only if you want the new default UI,
• republish migrations only when needed,
• verify media-kit config and routes if you use the shared media library.

Upgrading from 4.x to 5.x

• upgrade the host application to PHP 8.3+, Laravel 13.32+ and Livewire 4.4+ first,
• review published Livewire views before replacing them with the package defaults,
• if the host application customizes Livewire::setUpdateRoute(), update its callback to accept both $handle and $path, then register the route using the hash-aware $path supplied by Livewire 4,
• clear application caches after updating the package and run the host application's CMS and browser-facing regression tests.

License

MIT