*🚀 A Laravel-based publishing engine built for modern, modular communities*
Published CMS isn’t a finished “content management system” — at least, not yet.
Think of it instead as a **highly opinionated Laravel starter kit** designed to give developers a strong architectural foundation for building content-driven platforms.
At its core, Published CMS rethinks what a CMS should be in the era of APIs, federated content, and community platforms. It starts with a simple concept — *everything is a Post* — and builds a complete permission, policy, and service layer around that idea.
The goal: make it easy to build anything from a classic blog to a federated social platform, event community, or niche discussion hub — all with consistent, transparent rules.
---
## 🧩 A Layered Architecture
Published CMS is structured more like a **framework within Laravel** than a traditional CMS plugin.
It provides three robust layers already in place:
| Layer | Description |
| --- | --- |
| **Model Layer** | Clean Eloquent models for Posts, Categories, Comments, PostTypes, and their relationships. |
| **Service Layer** | Business logic extracted into dedicated service classes to ensure controllers remain thin and predictable. |
| **Policy & Validation Layer** | Laravel Policies, Requests, and Validators baked in for consistent authorization and validation across API and Livewire. |
This structure means that the backend is **largely complete and production-ready**, even though much of the front-end experience (Livewire and Blade components) is still under development.
In other words: the **API is real**, even if the **UI is provisional**.
---
## 🧠The Core Concept: Everything Is a Post
Taking a cue from WordPress’s data model, Published CMS uses a single `posts` table for all major content — whether that’s an article, an event, a venue, or a comment.
Different content types are distinguished through **PostTypes**, which define their behaviour and appearance.
For example:
- A “post” PostType could be a normal blog entry.
- An “event” PostType could include a date and time.
- A “venue” PostType could represent a reusable location object.
This abstraction allows developers to reuse the same CRUD logic, relationships, and permissions across radically different content types.
---
## đź”— Relationships That Matter
The model structure is deliberately expressive — designed for relational depth rather than flat documents.
- **Posts** belong to **Categories**.
- **Posts** can be **attached** to other posts (e.g., an event attaching a venue).
- **Comments** are treated as small posts in their own right, bound to parent posts.
- **Categories** can act like public tags *or* private groups, depending on configuration.
This flexibility makes the system suitable for everything from publishing platforms to community forums — all using the same primitives.
---
## 🛡️ Permissions and Policy System
One of the strongest architectural features is the **policy system**, which cleanly separates *rules* from *business logic*.
Every action a user can perform — creating, editing, attaching, deleting, or commenting — is validated through a corresponding **Policy class**.
Policies don’t make arbitrary decisions; they defer to **Category membership roles** and **Site-wide settings**.
### Key principles:
- **Global overrides** (SiteSettings) define platform-wide defaults, like whether posts can be updated or who can create categories.
- **Category-local roles** (user, mod, manager, owner) define what members can do within their group.
- **Per-post checks** ensure only authorized users can edit, attach, or delete content.
This layered approach makes permissions transparent, auditable, and easy to adapt as the product evolves.
---
## ⚙️ Site Settings: Configurable Logic
Instead of hard-coding assumptions, Published CMS stores much of its behaviour in **SiteSettings**.
This lets administrators change the personality of the platform without rewriting rules.
Examples include:
- Whether users can edit or delete their own posts.
- Who can create new categories or approve join requests.
- Whether restricted groups can send invitations.
- Whether post types are “blacklisted” or “whitelisted” per category.
This model bridges the gap between static configuration and dynamic administration, giving product managers a clear handle on how the system behaves globally.
---
## 🌍 Categories as Groups
In Published CMS, a “category” can behave in two distinct modes:
1. **Classic Category Mode** – simple taxonomy for organizing content.
2. **Group Mode** – private or semi-private communities with their own owners, moderators, and permissions.
When in Group Mode, categories function more like **Subreddits** or **Facebook Groups**:
- Each has an owner (the creator).
- Owners can promote moderators and managers.
- Membership requests and invitations are handled through built-in routes.
- Each group can control which PostTypes are allowed (events only, discussions only, etc.).
This makes group-based community building a first-class feature — not an afterthought.
---
## đź’¬ Comments as First-Class Citizens
Comments are stored as their own model, but designed to behave like micro-posts.
They obey the same authorization rules as full posts, and their visibility depends on both the post’s category and user permissions.
This consistency keeps the system logical for developers and predictable for users.
---
## 🔌 A Fully Functional API
While the frontend layer is still maturing, the **API is already comprehensive** — ready for integration with SPAs, mobile apps, or third-party clients.
The API is split into **public** and **protected** namespaces:
### Public Endpoints (`checkApiKeyOptional`)
Designed for browsing, fetching, and discovery:
- `/posts`, `/categories`, `/post-types`, `/comments`
- `/prompts` (for AI-assisted content creation)
- `/deadletter` (for encrypted, anonymous message drops)
### Protected Endpoints (`checkApiKey`)
Designed for content creation and management:
- Create, update, and delete posts
- Attach or detach related posts
- Manage metadata, comments, and revisions
- Control category membership and roles
- Adjust global SiteSettings
- Manage PostTypes dynamically
Although some routes (like `ApiClientController`) are placeholders, the majority of the content, category, and comment functionality is already working end-to-end.
---
## 🧱 Building Philosophy: Opinionated but Extensible
Published CMS takes a clear stance: **good architecture beats flexibility by accident.**
Rather than leaving developers to reinvent validation, authorization, and logic scattering, it offers:
- Centralized **Validators** and **Services** for each model.
- Clean, consistent **Policy enforcement**.
- A robust, **testable API** foundation.
This makes it ideal for teams who want to start from a *well-designed core* and evolve the UI and features in their own direction — whether that’s a publishing platform, social app, or multi-tenant SaaS.
---
## 🧠Where It’s Heading
The roadmap focuses on completing the **frontend layer** — building Livewire components and Blade templates that demonstrate how the backend services tie together visually.
Planned milestones include:
- A unified post creation and editing interface.
- Category and group management dashboards.
- A modular comment and attachment system.
- Extensible API client registration and analytics.
As it evolves, Published CMS aims to serve as both a **standalone CMS** and a **developer framework** for any content-centric product.
---
## 🪶 In Summary
Published CMS is not “another CMS.”
It’s a foundation — a well-architected Laravel starter kit that solves the hardest backend problems of publishing platforms so that developers and product teams can focus on what matters most:
> Building communities, not just content.
It already provides the **core intelligence** — relationships, rules, and API endpoints.
What comes next is the **presentation layer** that makes it shine.
Published CMS isn’t a finished “content management system” — at least, not yet.
Think of it instead as a **highly opinionated Laravel starter kit** designed to give developers a strong architectural foundation for building content-driven platforms.
At its core, Published CMS rethinks what a CMS should be in the era of APIs, federated content, and community platforms. It starts with a simple concept — *everything is a Post* — and builds a complete permission, policy, and service layer around that idea.
The goal: make it easy to build anything from a classic blog to a federated social platform, event community, or niche discussion hub — all with consistent, transparent rules.
---
## 🧩 A Layered Architecture
Published CMS is structured more like a **framework within Laravel** than a traditional CMS plugin.
It provides three robust layers already in place:
| Layer | Description |
| --- | --- |
| **Model Layer** | Clean Eloquent models for Posts, Categories, Comments, PostTypes, and their relationships. |
| **Service Layer** | Business logic extracted into dedicated service classes to ensure controllers remain thin and predictable. |
| **Policy & Validation Layer** | Laravel Policies, Requests, and Validators baked in for consistent authorization and validation across API and Livewire. |
This structure means that the backend is **largely complete and production-ready**, even though much of the front-end experience (Livewire and Blade components) is still under development.
In other words: the **API is real**, even if the **UI is provisional**.
---
## 🧠The Core Concept: Everything Is a Post
Taking a cue from WordPress’s data model, Published CMS uses a single `posts` table for all major content — whether that’s an article, an event, a venue, or a comment.
Different content types are distinguished through **PostTypes**, which define their behaviour and appearance.
For example:
- A “post” PostType could be a normal blog entry.
- An “event” PostType could include a date and time.
- A “venue” PostType could represent a reusable location object.
This abstraction allows developers to reuse the same CRUD logic, relationships, and permissions across radically different content types.
---
## đź”— Relationships That Matter
The model structure is deliberately expressive — designed for relational depth rather than flat documents.
- **Posts** belong to **Categories**.
- **Posts** can be **attached** to other posts (e.g., an event attaching a venue).
- **Comments** are treated as small posts in their own right, bound to parent posts.
- **Categories** can act like public tags *or* private groups, depending on configuration.
This flexibility makes the system suitable for everything from publishing platforms to community forums — all using the same primitives.
---
## 🛡️ Permissions and Policy System
One of the strongest architectural features is the **policy system**, which cleanly separates *rules* from *business logic*.
Every action a user can perform — creating, editing, attaching, deleting, or commenting — is validated through a corresponding **Policy class**.
Policies don’t make arbitrary decisions; they defer to **Category membership roles** and **Site-wide settings**.
### Key principles:
- **Global overrides** (SiteSettings) define platform-wide defaults, like whether posts can be updated or who can create categories.
- **Category-local roles** (user, mod, manager, owner) define what members can do within their group.
- **Per-post checks** ensure only authorized users can edit, attach, or delete content.
This layered approach makes permissions transparent, auditable, and easy to adapt as the product evolves.
---
## ⚙️ Site Settings: Configurable Logic
Instead of hard-coding assumptions, Published CMS stores much of its behaviour in **SiteSettings**.
This lets administrators change the personality of the platform without rewriting rules.
Examples include:
- Whether users can edit or delete their own posts.
- Who can create new categories or approve join requests.
- Whether restricted groups can send invitations.
- Whether post types are “blacklisted” or “whitelisted” per category.
This model bridges the gap between static configuration and dynamic administration, giving product managers a clear handle on how the system behaves globally.
---
## 🌍 Categories as Groups
In Published CMS, a “category” can behave in two distinct modes:
1. **Classic Category Mode** – simple taxonomy for organizing content.
2. **Group Mode** – private or semi-private communities with their own owners, moderators, and permissions.
When in Group Mode, categories function more like **Subreddits** or **Facebook Groups**:
- Each has an owner (the creator).
- Owners can promote moderators and managers.
- Membership requests and invitations are handled through built-in routes.
- Each group can control which PostTypes are allowed (events only, discussions only, etc.).
This makes group-based community building a first-class feature — not an afterthought.
---
## đź’¬ Comments as First-Class Citizens
Comments are stored as their own model, but designed to behave like micro-posts.
They obey the same authorization rules as full posts, and their visibility depends on both the post’s category and user permissions.
This consistency keeps the system logical for developers and predictable for users.
---
## 🔌 A Fully Functional API
While the frontend layer is still maturing, the **API is already comprehensive** — ready for integration with SPAs, mobile apps, or third-party clients.
The API is split into **public** and **protected** namespaces:
### Public Endpoints (`checkApiKeyOptional`)
Designed for browsing, fetching, and discovery:
- `/posts`, `/categories`, `/post-types`, `/comments`
- `/prompts` (for AI-assisted content creation)
- `/deadletter` (for encrypted, anonymous message drops)
### Protected Endpoints (`checkApiKey`)
Designed for content creation and management:
- Create, update, and delete posts
- Attach or detach related posts
- Manage metadata, comments, and revisions
- Control category membership and roles
- Adjust global SiteSettings
- Manage PostTypes dynamically
Although some routes (like `ApiClientController`) are placeholders, the majority of the content, category, and comment functionality is already working end-to-end.
---
## 🧱 Building Philosophy: Opinionated but Extensible
Published CMS takes a clear stance: **good architecture beats flexibility by accident.**
Rather than leaving developers to reinvent validation, authorization, and logic scattering, it offers:
- Centralized **Validators** and **Services** for each model.
- Clean, consistent **Policy enforcement**.
- A robust, **testable API** foundation.
This makes it ideal for teams who want to start from a *well-designed core* and evolve the UI and features in their own direction — whether that’s a publishing platform, social app, or multi-tenant SaaS.
---
## 🧠Where It’s Heading
The roadmap focuses on completing the **frontend layer** — building Livewire components and Blade templates that demonstrate how the backend services tie together visually.
Planned milestones include:
- A unified post creation and editing interface.
- Category and group management dashboards.
- A modular comment and attachment system.
- Extensible API client registration and analytics.
As it evolves, Published CMS aims to serve as both a **standalone CMS** and a **developer framework** for any content-centric product.
---
## 🪶 In Summary
Published CMS is not “another CMS.”
It’s a foundation — a well-architected Laravel starter kit that solves the hardest backend problems of publishing platforms so that developers and product teams can focus on what matters most:
> Building communities, not just content.
It already provides the **core intelligence** — relationships, rules, and API endpoints.
What comes next is the **presentation layer** that makes it shine.