Laravel Addon CMS

Laravel Addon CMS started from a simple irritation: too many CMS projects become a pile of copied code. A blog module, a contact form, a language switcher, analytics scripts, cookie consent, invoice features, newsletter forms: each one starts reusable, then gets welded into a client project until nobody wants to update it.

The system exists to keep that boundary visible. The core should not know every future feature. It should provide the admin shell, the database-backed settings layer, media handling, theme content storage, SEO configuration, addon installation and the loader that decides what is active. Everything else should be a package with its own folder, provider, routes and lifecycle.

That is why the repository is open source. It is not trying to be a polished SaaS product with a locked roadmap. It is a Laravel codebase other developers can inspect, run, change, build addons for, build themes for and improve.

The database decides what the app loads

At boot, the application checks whether the addon and theme tables exist. Once the system is installed, it reads active addons from the addons table and registers each matching service provider from app/Addons/{AddonName}. Then it reads the active_theme option and registers the matching provider from app/Themes/{ThemeName}.

That gives the CMS its main behavior: enabling an addon is not a config-file edit, and switching a theme is not a deploy. The admin state changes what providers boot, which routes exist, which views are namespaced, which sidebar items appear and which theme sections are available.

Theme content is stored in theme_contents and cached after load. Theme section classes describe fields such as text, URLs, images and repeaters. The admin customizer uses those definitions to build editing forms, validates the submitted fields, stores JSON content, and previews changes inside an iframe. On the public side, a section loader loops through the active page sections and includes the matching Blade section view.

An addon is a Laravel feature package inside the app

Addons live in app/Addons/{AddonName}. A typical addon has a service provider, Activator class, composer.json metadata, routes, controllers, models, views, assets and database migrations. The service provider loads routes and views, then optionally registers admin sidebar items or frontend sections.

PostCraft is the plain example: it loads cms_postcraft.php, registers its views under a PostCraft namespace, and adds Blog Posts menu items to the admin sidebar. MailMate shows the more interesting path: it registers subscriber admin screens and also registers pushable newsletter sections that a theme page can include.

The Activator class gives an addon lifecycle methods for activate, deactivate and delete. During activation the CMS runs the addon migration path with Artisan before marking it active. During deletion it rolls migrations back, calls the addon delete hook, removes the folder and deletes the database row. That is intentionally simple: Laravel developers should recognize the moving parts immediately.

How to build a new addon

Install the command helper package, then scaffold the addon. The project already requires amdadulshakib/cmsaddoncommands, which adds Artisan commands for addon development.

1# Create the addon folder and its base files2php artisan make:addon Blog3 4# Generate the feature classes5php artisan addon:model Blog Post -m6php artisan addon:controller Blog PostController7php artisan addon:migration Blog create_posts_table8 9# Run or roll back only this addon's migrations10php artisan addon:migrate Blog11php artisan addon:migrate:rollback Blog

Register routes, views and the admin menu

1<?php2 3namespace App\Addons\Blog;4 5use App\Lib\Sidenav;6use Illuminate\Support\ServiceProvider;7 8class BlogServiceProvider extends ServiceProvider9{10    public function boot(): void11    {12        $this->loadRoutesFrom(__DIR__.'/routes/cms_blog.php');13        $this->loadViewsFrom(__DIR__.'/views', 'Blog');14 15        Sidenav::add('Content', 'Blog posts', 'admin.blog.index', 'ph ph-article');16    }17}

After scaffolding, fill the service provider: load the addon route file, load views with a namespace, add any admin menu entries through Sidenav, and register any pushable sections if the addon has frontend blocks. Keep composer.json accurate: nickname must match the folder and service provider naming convention, version should reflect the addon release, and required_addons or required_system_version should be declared when the addon depends on another piece of the system.

• Keep the addon nickname identical to its folder and service-provider prefix.
• Put database changes inside the addon migration directory so activation and deletion remain reversible.
• Use the addon view namespace instead of reaching into another addon or the active theme.
• Declare required_addons and required_system_version before distributing the addon ZIP.
• Implement activate, deactivate and delete hooks only for lifecycle work that migrations cannot handle.

A theme owns pages, sections and presentation

Themes live in app/Themes/{ThemeName}. A theme usually contains a service provider, routes, controller, Lib section classes, Blade layouts, section views, slice views for repeaters, assets, config.json and a screenshot. The service provider loads the theme routes and views, shares theme asset helpers, registers configurable sections and registers public pages.

A section class is a small contract between code and the admin UI. Its static register method receives the active ThemeConfig instance. It passes an array to addSection for the section key, title, supported pages and position, then passes field-definition arrays to addField. Repeatable content uses addRepeaterGroup and addRepeaterField.

1<?php2 3namespace App\Themes\YourTheme\Lib;4 5class HeroSection6{7    public static function register($themeConfig): void8    {9        $themeConfig->addSection([10            'key' => 'hero_section',11            'pages' => ['home'],12            'position' => 1,13            'title' => 'Hero Section',14        ]);15 16        $themeConfig->addField('hero_section', [17            'type' => 'text',18            'key' => 'heading',19            'label' => 'Heading',20            'default' => 'Build something useful',21        ]);22 23        $themeConfig->addField('hero_section', [24            'type' => 'image',25            'key' => 'image',26            'label' => 'Hero Image',27            'size' => '1200x800',28            'accept' => '.png,.jpg,.jpeg,.webp',29            'default' => load_image(30                'app/Themes/YourTheme/assets/images/hero.jpg'31            ),32        ]);33 34        $themeConfig->addField('hero_section', [35            'type' => 'url',36            'key' => 'button_url',37            'label' => 'Button URL',38            'attr' => 'href',39            'default' => '#',40        ]);41    }42}

To build a new theme, create app/Themes/YourTheme, add YourThemeServiceProvider, load views as Theme, define routes, create Lib classes for sections, create matching Blade files in views/sections, and put repeater item templates in views/slices/{section_key}/{repeater_key}. Register pages with register_pages so the customizer knows which pages exist. Add a row in the themes table or seed data, then set active_theme in basic_settings to activate it.

1<section class="hero-section">2    <div class="container">3        <div class="hero-content">4            <h1>5                <x-ui.text section="hero_section" key="heading" />6            </h1>7 8            <x-ui.a9                class="btn"10                section="hero_section"11                key="button_url"12            >13                Learn more14            </x-ui.a>15        </div>16 17        <x-ui.img18            class="img-fluid"19            section="hero_section"20            key="image"21            alt="Hero image"22        />23    </div>24</section>

These UI components are important. They resolve the saved theme content and preserve the CMS editing hooks used by the customizer. Reading values directly from a $content array would bypass the convention used throughout Brixly and make the example misleading.

• Service provider: loads routes and views, then registers pages and section classes.
• Lib directory: defines the editable field schema consumed by the admin customizer.
• views/sections: contains one Blade view for each registered section key.
• views/slices: renders repeatable items such as testimonials, logos or service cards.
• config.json and screenshot.png: identify and present the theme in the admin panel.
• assets: contains theme-owned CSS, JavaScript, images and fonts.

The architecture got more attention than the interface

The current UI/UX is not the strongest part of the project, and that is intentional to say plainly. Most of the early energy went into code structure: addon boundaries, theme registration, migration lifecycle, content configuration, seeded installs and making the project understandable to Laravel developers.

That trade-off made the system easier to extend, but it leaves visible work in the admin experience. The customizer, media manager, addon screens and theme controls can be cleaner, faster and more polished. A better design pass would not change the core idea; it would make the same architecture easier for non-technical users to trust.

Where contributions would help

The project is MIT licensed, and contributions are welcome. Useful contributions are not limited to big features. Documentation improvements, install notes for different hosting environments, UI polish, bug fixes, tests, better validation, accessibility fixes, new theme sections, new themes, and well-scoped addons all help.

The best contribution style is small and specific: one addon, one theme section, one admin workflow, one failing test, one documentation gap. The project benefits more from clear pull requests than from large rewrites that make the extension model harder to follow.

What I would keep and what I would improve

I would keep the separation between core, addons and themes. I would keep the Laravel-native shape: service providers, route files, Blade views, migrations, Artisan commands and Composer metadata. The reason the system is approachable is that it does not ask Laravel developers to learn a private framework before they can extend it.

I would improve the admin interface, add more automated tests around addon install/activate/delete flows, document the theme section API more thoroughly, and make the demo data smaller and easier to reason about. The project has the right skeleton; the next work is polish, guardrails and a better contributor path.