Cms Laravel Package

Product Decisions This Supports

• Build vs. buy for content authoring. v0.4.0 replaces the field-by-field element editing flow with a Notion-like document editor: continuous running text with headings, bold, italic, lists, quotes and links, plus //-triggered inline element insertion. This is the single biggest differentiator for editor adoption — it lets you credibly evaluate "keep it in-house" against per-seat licensing for Notion, Craft, Storyblok or a hosted Tiptap/ProseMirror editor. If your authors already compare your admin to Notion, this release closes that gap without a vendor contract.
• Content model architecture / roadmap commitments. The new shared contents / content_elements base, the ExtendsContent concern and the ContentTypeRegistry turn the CMS from a page-and-element system into a general content platform. This unlocks roadmap items that previously required a bespoke model per feature: documentation, blog/news, help-centre articles, structured landing blocks, and any module-specific content type registered by another package. It is the decision point for "one CMS for the whole product" versus "CMS for pages plus a separate tool for everything else."
• Migration and data-continuity risk. The migration moves existing pages and elements into the new base while preserving ids. As PM, treat this as a release-gating item: ids surviving means URLs, redirects, analytics annotations, backlinks and external references keep working, which is exactly the property that lets you upgrade in place instead of scheduling a content freeze and re-import. Get a written confirmation and a rollback plan, and run it against a production snapshot with real content volume before committing a date.
• Front-end delivery and dependency posture. The editor ships as the module's own Tiptap bundle (dist/build), served by the route cms.asset. That is a real product decision in your favour — no CDN dependency, no third-party editor runtime reaching your admin from outside your perimeter, no surprise CDN outage on publishing day — but it makes asset versioning and cache invalidation your responsibility. Add "editor bundle renders correctly after deploy" to your release checklist.
• Content safety and sanitation. Running text is stored as a new rich_text element and sanitised on save. This is the input to your content-security and legal review: confirm the sanitiser strips scripts and unsafe attributes on save (not just render), and that it is applied to every path including the // inline insert and any API or import surface. If your product has regulated or user-contributed content, request the sanitiser's allow-list in writing.
• Upgrade cost and internal consumer inventory. element-page-detail, element-picker-modal and the EditsContentElements trait are gone, replaced by EditsContentDocument. Before you commit to the version, have engineering grep every internal package, admin customisation, theme and Blade/JS override that touches those three names. This is the line item that decides whether v0.4.0 lands this sprint or next.

When to Consider This Package

Consider adopting (or accelerating your upgrade to) v0.4.0 when:

• Authors live in the CMS daily. The document editor is the point. If your content team's complaint is "this is slower than Google Docs," v0.4.0 is the release that answers them, and the ROI shows up as reduced authoring time and fewer support tickets.
• You expect more than one content type. The ContentTypeRegistry and ExtendsContent concern only pay off if something is going to register a content type. If your roadmap includes docs, news, help articles or module-owned content, adopting this base now avoids a second migration later.
• You are standardising on one admin. Shared content base means consistent editing, permissions and sanitation across content kinds — valuable if you are consolidating tools and cutting licences.
• You need in-perimeter front-end assets. Self-hosted Tiptap bundle is the right answer for strict CSP, air-gapped, government or regulated deployments where a CDN-hosted editor is a non-starter.
• You can absorb a breaking upgrade. You have engineering capacity to audit and update customisations, and a staging environment with representative content.

Look elsewhere or defer when:

• You have no customisations but also no authoring pain. If a plain field-based editor is fine and nobody is complaining, the upgrade risk buys you little; take it opportunistically, not urgently.
• Your integration surface is heavy. If third-party code, custom admin panels or a bespoke front end depends on the removed element-picker-modal / element-page-detail components or the EditsContentElements trait, budget the rework explicitly before choosing this version — or pin and upgrade later.
• You need a WYSIWYG that non-developers can extend. The bundle is the module's own; changing toolbar behaviour or adding custom Tiptap extensions means touching dist/build and the asset route. If you need a heavily customised editing surface with no PHP-side build step, a headless CMS with a maintained editor SDK may fit better.
• You need versioned, reviewable content workflows. A Notion-like editor is optimised for fast authoring, not for editorial approval chains. If scheduled publishing, multi-stage review or audit trails are hard requirements, check those before treating v0.4.0 as sufficient.
• The package is on a pre-1.0 cadence and you need stability guarantees. v0.4.0 removing three public-facing names is a signal: expect further breaking changes. Adopt with a pinning strategy and a migration budget, not as a load-bearing long-term bet without that caveat written down.

How to Pitch It (Stakeholders)

To executives: v0.4.0 makes our CMS a content platform rather than a page editor. Two things change commercially. First, authors get a modern, document-style editor — the kind of experience people expect from Notion — which is the main lever on adoption and on whether we can consolidate content tooling and drop per-seat licences. Second, content is now organised on a shared foundation that other parts of the product can extend, so future content types (documentation, news, help articles, module-owned content) do not each need a separate build or a separate vendor. The upgrade is in place: existing pages and elements are migrated with their ids intact, so links and analytics references survive. The cost is a focused engineering effort to update anything that used the three components this release removes. Recommendation: approve the upgrade, gated on a production-snapshot migration rehearsal and an inventory of affected customisations, and expect to pin the version given the pace of change.

To engineering: This is a breaking release with a data migration. The new shared contents / content_elements base, ExtendsContent concern and ContentTypeRegistry are the architecture we should build on — register content types rather than adding parallel models. The migration preserves ids, which is what makes the upgrade safe, but it needs a rehearsal on a production snapshot and a rollback plan. Removed: element-page-detail, element-picker-modal and the EditsContentElements trait, replaced by EditsContentDocument — please grep the whole codebase, including custom admin panels and theme overrides, and list every touchpoint before we schedule. The editor is a self-hosted Tiptap bundle in dist/build served through the cms.asset route: add it to deploy and cache-invalidation checks, and confirm the sanitiser applied to the rich_text element covers the // inline-insert path as well as normal saves. Please also pin the version and note that pre-1.0 means further breaking changes are likely.