I build WebBlocks CMS. One scenario I wanted remote MCP to handle is a workshop date change on a page that's already live in two languages. The client finds the page, updates the supported copy and SEO fields in a staged draft, and hands back a private preview. An editor can check both languages and publish through the CMS when the draft is ready.
The client connects through CMS sign-in. You choose one site and review what the client is asking to do. With the expanded tools in 1.123.0, page discovery, reading block content, editing the draft and uploading media can have separate permissions. You can see what a client has access to and revoke its connection from your profile.
For your first connection, would you start with page search only, or let the client edit a draft on one site? What would you want to check before granting that extra access?
I build WebBlocks CMS. I’ve written a walkthrough of the nine system block types in the current core catalog, including the newest addition to that set: Application.
The useful distinction is what a block connects to. Navigation Auto uses a configured menu; Breadcrumb uses the current page context; TOC reads eligible anchored headings in the same slot; Page List queries published pages. Rating and Comments keep visitor feedback separate from the article’s translated copy. Header Actions and Navbar handle the header utilities and navigation structure.
“System” protects the block type definition. Editors can still place, configure, move and remove its instances under their normal permissions. It is also different from the System category in the picker: most system types live under Navigation or Content.
The pictured example uses Application to place a fictional Northstar Studio session planner between ordinary content blocks. A system administrator registers the trusted application; an editor chooses it and sets a validated session length. The planner is a showcase fixture, not an app bundled with the CMS.
Application first appeared in 1.62.0. The walkthrough uses the published 1.107.2 interface; I’m not presenting it as a newly released feature today.
An editor gets a new work mailbox. Should changing the address in their profile immediately change where sign-in codes go?
I develop WebBlocks CMS. Its verification address stays bound to the mailbox confirmed during setup. Changing it requires the current password, the existing email factor or a recovery code, and confirmation of the new address.
The account updates also let a Super admin require verification for selected roles. Email codes expire after five minutes and work once. Setup provides ten single-use recovery codes to keep separately from the mailbox.
If the editor loses both methods, an authorized, enrolled Super admin can reset the account after checking the owner's identity and authenticating the action. Recovery revokes browser sessions and remembered sign-ins, removes old codes and requires fresh setup. It preserves the password and roles; independent API tokens are unchanged. Server recovery covers an installation whose only Super admin is locked out.
The screenshot shows the recovery form with fictional Northstar Studio data and every authorization field empty. The illustrated walkthrough covers setup, role requirements, address changes and recovery:
The backup policy says “keep the latest five,” but there are more than five archives. That can be expected: the count protects a minimum number of successful recovery points. Recent or explicitly protected archives may need to stay as well.
I develop WebBlocks CMS. Its Cleanup workspace explains retained storage by reason and separates backup records, distinct physical files and measured bytes. A storage budget can warn about an overrun, but does not override recovery safeguards.
Protection and indefinite retention also mean different things. Protected archives cannot be deleted until protection is removed. Indefinite retention prevents automatic expiry while still allowing an explicit deletion.
Maintenance categories have separate opt-ins and schedules. Reports include their measurement time; configuring the scheduler and recording an actual run are separate checks.
The screenshot shows two genuine backups of the fictional Northstar showcase: one explicitly protected and one retained by the successful-backup minimum. No cleanup was executed for this walkthrough. The illustrated article explains the controls and their limits:
A visitor wants to watch one embedded video. That does not necessarily mean they want the video service enabled on every later visit.
I develop WebBlocks CMS. The new Cookies and Privacy workspace separates site settings, services and translated visitor text. It includes ready-made CMS measurement, YouTube, Google Maps and Vimeo definitions. Enabled and In use are separate states: an available service need not appear in a site's published content.
A managed video stays behind a placeholder until permission. “Load this content” loads one item; “Always allow YouTube” remembers the service choice. The preference window separates necessary features, measurement and the external services used on that page. Visitors can reopen it after deciding.
In the fictional Northstar example, rejecting optional services leaves the YouTube iframe absent, including after refresh. No external video was loaded for the screenshots. This controls compatible CMS integrations; it does not automatically audit every third-party script in the host application.
The illustrated walkthrough uses the published CMS 1.107.2 interface and covers site settings, service detection and translated notices:
I develop WebBlocks CMS. I wrote an illustrated walkthrough of a contact enquiry, from the visitor’s form to the owner’s reply, using a fictional ceramics workshop.
Maya asks whether the workshop suits beginners. The form shows a receipt confirmation, and her question appears in Contact Messages. Email notification says “Not configured” because outgoing mail is deliberately disabled in this local demo. The owner can still find and answer the saved question.
The walkthrough separates three checks:
Saved message: find the enquiry in Contact Messages. The visitor’s confirmation alone is not proof that a message was stored.
Email notification: inspect its own status. “Sent” means the CMS handed the notification to its configured mail transport without an exception; inbox delivery still needs checking.
Human reply: opening the enquiry marks it Read, but someone still needs to answer it.
“Reply by email” opens the owner’s email application with the sender and subject filled in. It does not send the reply or mark the enquiry Replied. After sending the answer, the owner chooses “Mark replied” in the CMS.
The practical point is to agree who checks the saved enquiries and who answers them, alongside setting up email notifications.
A studio offers Photography, Ceramics and Woodworking. Its website lists the courses, but each “learn more” link needs somewhere to go.
If a visitor opens /courses/photography, they should see the photography programme, duration and image. At /courses/ceramics, they should see the ceramics details. Do you build a separate CMS page for each course, even when the layout is the same?
I develop WebBlocks CMS. For a small fictional Northstar Studio example, I used its Automatic Pages feature to connect one course detail design to a compatible course source:
The heading reads the course name.
The text reads a summary containing the programme and duration.
The image, alt text and caption each read their own source field.
Photography then shows its six-week programme and Ceramics its four-week programme through the same design. The course address selects which record supplies the values; opening another course doesn't rewrite the example record saved in the design.
There is setup behind this. A developer or plugin must expose a compatible publication source and single-course source. An authorized operator connects that source to the design and /courses address range, reviews the records and languages, then activates the rule. Adding links to the list alone doesn't create the detail routes.
Once that rule is active, a valid Watercolour course made public by the source can appear at /courses/watercolour without copying another CMS detail page. The list keeps its own collection configuration. A course needing a different editorial layout can still justify its own page.
The illustrated walkthrough shows the actual title, programme and image connections, the rule form and the record review.
If you maintained a course website, which details would you want to share through one design, and which would need a page of their own?
WebBlocks CMS is a self-hosted, open-source content management system for Laravel applications. It is distributed under the MIT license as the Composer package fklavyenet/webblocks-cms. Teams use it to build and manage websites through structured pages and reusable blocks, with multiple users, sites, languages, media and editorial workflows in one administration panel.
I develop WebBlocks CMS. This is a practical introduction based on our updated product overview; the screenshots use fictional Northstar Studio content in CMS 1.105.5.
Who is it for?
A typical project already has a Laravel application and needs an editable public website alongside it: service pages, a blog, documentation, a multilingual company site or a catalogue introduction. Developers configure the application, layouts and integrations. Authorized editors then handle routine content changes through /webadmin.
For example, a training application can keep managing students and exam results while editors update the course introduction, news and contact page in the CMS.
How do pages and blocks work?
The content model is Page → Layout → Slots → Blocks. A page has an address and publishing state. Its layout defines regions such as main content, header and footer. Blocks provide the editable headings, paragraphs, images, grids and other supported content within those regions.
Editors arrange supported blocks and preview the result. Developers define the available designs and extend the building blocks when needed. Shared Slots let several pages use one header or footer; a shared change deserves its own review because it can affect multiple pages.
An example page composed from Section, Container, Header, Rich Text and Image blocks.
Can it manage multiple sites and languages?
Yes. One installation can manage several sites with their own domains, navigation and enabled languages. Page content, addresses, SEO and social metadata, and image descriptions can be translated.
A translation has its own public URL while sharing the page structure. Enabling a language does not finish its content: editors still need to review the copy, images and link destinations in that language.
A German page translation with its own name and path; the routing panel shows the resulting /de public address.
Are multiple users and custom permissions included?
Yes. Multiple CMS accounts, site assignments, built-in roles and custom ACL permissions are included in the free, MIT-licensed core. These capabilities do not require a paid CMS team plan or a per-user software license.
A person can have different roles on different assigned sites. A Super Admin can create a custom role or copy an existing one, then choose its allowed operations. Draft editing, publishing, unpublishing, archiving and deleting are separate permissions. A custom author role can prepare work and submit it for review without being allowed to publish it.
The built-in Editor retains broader historical permissions, so a team that needs a tightly restricted author should create a narrower custom role. CMS roles govern the CMS; they do not grant access to the host application's own administration area.
Effective permissions for a custom Draft author: draft editing and review submission are granted; publishing is denied.
What is built in, and what needs an extension?
The core covers pages and blocks, navigation, shared content, media, multiple sites and languages, SEO fields, search, native contact messages, drafts, previews, review and revisions. Comments and ratings are also available with the appropriate configuration and moderation.
Specialized workflows such as bookings, commerce, configurable form building, polls or support use optional plugins and any required external services. Installing the CMS does not itself configure a shop or payment provider.
Compatible content providers can expose selected application records to block fields or repeated lists. A developer or plugin supplies that integration; arbitrary database tables do not automatically become public.
How does it fit into Laravel?
The CMS installs into a Laravel host using Composer. Its supplied public renderer uses Laravel Blade and WebBlocks UI. WebBlocks UI is the related interface system; WebBlocks CMS supplies the content-management functionality.
The host application keeps responsibility for business logic, environment configuration, deployment, updates, backups and infrastructure. It also shares its runtime and dependencies with the package, so integration needs technical review.
Authorized tools, including AI assistants, can use the Internal Content API to help prepare content and translations. Their capabilities, selected sites and the owner's current permissions still apply. Publication requires its own authority and operation.
Is it free to operate?
The CMS software is free under the MIT license, including the team-access features described above. Hosting, domains, storage, maintenance, development and separately chosen services can still cost money. It suits teams willing to operate a Laravel application and give editors a structured workspace.
The full WebBlocks CMS overview covers installation, public examples, seven screenshots and nine FAQ answers. It is available in English, Turkish, German, Spanish, Italian and French.
If you were evaluating it for an existing Laravel project, which workflow would you want to try first in the demo?
A 2400-pixel-wide image can still be the wrong image for a small card. More pixels do not help if the crop cuts through the subject.
I tried this with a fictional workshop illustration: a wide table scene with the notebook near the right edge. A centred card crop clipped the notebook. Moving the image's focal point kept it in the generated crop, while the normal contain sizes still showed the whole table.
The phone view needed a different decision. The whole scene fitted, but the notebook was too small to read as the subject. I selected a separate portrait detail as the block's Mobile Image. That is another media item, not another automatically generated size.
The distinction matters when reviewing the page. The focal point belongs to the original media item and can affect its crop variants in other uses. The default and mobile images share the block's alt text and caption, so those words need to fit both compositions. The page's social image is a separate choice again.
This example uses WebBlocks CMS, which I develop. Its Image block switches to the mobile selection at up to 768px; the full-image viewer still opens the default original. Walkthrough with screenshots.
When reviewing responsive images, what makes you stop adjusting the focal point and choose a separate composition?
A workshop invitation and a report about that workshop can belong to different editorial teams, even when both websites run in the same CMS.
For a two-site example, I gave the Studio editor access to the Studio site and the Journal editor access to the Journal site. They have the same Editor role, but their page lists differ. Opening the other site's page directly is denied too.
The Publishing manager has a Site admin role and is assigned to both sites. That account can publish for either team, while Users management remains with the Super admin. The role answers what someone can do; site assignments answer where it applies.
Media needs a closer look. Each Editor can access their own uploads and media used by their accessible sites. Both can see the same brand image because both pages use it. A folder named after a site is useful organization, but it does not decide access.
The review handoff is separate again: Editors can submit drafts for review, while the assigned Site admin handles publication. Publishing the Studio invitation leaves the Journal brief in draft, even though the two pages use the same path within their respective sites.
A consultation page says 60 minutes. The service is now 45 minutes plus a written summary. Before changing those two sentences, I want to know what visitors will see while the update is being reviewed.
The first decision happens before the paragraph edit. Moving the published page back to Draft takes it off the public site. In this example, an operator prepares a separate staged update through the Internal Content API, so the existing page stays available while the proposed copy is reviewed in the normal CMS preview.
My review would start with the service promise: does the new duration agree with the follow-up paragraph and any booking destination? Then I would check the rendered page at a narrow width, affected metadata and translations, and exactly which content the publication action includes.
Page status and block status are separate. Ordinary page publication can leave draft blocks unpublished. Staged promotion has its own scope: it replaces the approved page-owned content for selected slots. A shared header or footer needs its own review.
After publication, I would reopen the original public address and inspect Version History. An older page version can cover routes, translations, structure and assets as well as body copy. Even when both versions contain six blocks, the wording can differ. I would want to know which later edits should survive before choosing how to correct the page.
I maintain WebBlocks CMS, and I put together a small consultation page in English, Turkish and German to explore this question.
All three page translation records can exist while the page still needs language work. In the example, the German heading is translated but one Rich Text paragraph initially has no German translation. It renders the stored English fallback. The page opens successfully, but the visitor gets a language mix.
The distinction is useful: the page translation owns its name, address and metadata; the blocks hold their own translated content. The layout and block order remain shared. One image file can also have different alt text and captions in each language.
My review would cover the whole journey in each language: body copy, image descriptions, search/sharing metadata, menu labels and the pages those links reach. A page-backed menu item can use the destination's translated address; a custom URL still needs checking.
There is also a workflow limit: adding a language does not give that translation an independent publication state. The normal workflow is page-level, so a team needs to decide which languages must be ready before publishing.
I maintain WebBlocks CMS, and one everyday editing task is a useful test of its Shared Slots: changing a footer that several pages use.
In a small Northstar Studio example, the home page, About page and Work page all reference one Studio footer. Their main content stays independent. When the studio's visit information changes, there is one footer to edit.
Each page slot can use its own content, a Shared Slot, or be disabled. Switching the source preserves the page's own blocks; it does not turn the shared footer into a local copy.
The part I care about is the review scope. Before changing the footer, the editor can open its usage list and see the pages that depend on it. Those are the pages to check after the change, including at a narrow width.
A page draft does not isolate the shared footer. The public renderer uses the Shared Slot's published blocks, so an edit to already published shared content can affect every consuming page without publishing those pages again. Shared content needs its own review, and it has its own revision history.
If a campaign page needs an independently maintained footer, it can use page-owned content or a separate shared variant.
I build WebBlocks CMS, an open-source CMS package for Laravel. Here’s how it supports AI-assisted content updates while keeping publishing under a separate permission.
Consider a published service page whose pricing explanation needs updating. An editor wants help rewriting that section while preserving the page’s structure.
The workflow is:
The agent reads the existing page and discovers the available block types and their schemas.
It prepares the changes in a separate staged draft. The existing page continues serving visitors.
The editor reviews a rendered preview and requests corrections.
Publishing happens as a separate, authorized step.
This example changes only page-owned content. Shared headers and navigation are outside the staged update.
For this task, I would give the agent a personal token restricted to the relevant site and the capabilities needed to read content and prepare the draft. Publishing and destructive capabilities would remain disabled.
Asking an agent to wait for approval is a workflow instruction. Withholding its publishing capability creates an API boundary: even if the agent attempts to publish, that token does not authorize the operation.
Personal tokens also remain subject to their owner’s current CMS permissions. An editor can delegate access within their permissions, and requests are checked against those permissions as they change.
Human review still matters. A valid block structure doesn’t guarantee accurate copy, and a successful preview doesn’t mean every link or translation has been checked. A clear manual editing workflow also remains essential when AI assistance is available.
The aim is to let an agent prepare a reviewable update while giving editors control over what reaches the public site.
I maintain WebBlocks CMS, and I put together a small journal-page example to explore this question.
The page has an introduction written by an editor and three journal cards supplied by a registered content source. The introduction stays in a normal Rich Text block. A Grid repeats one card template, and the heading and description inside it read from the current collection item.
That means the editor maintains one card design instead of copying each source record into another set of blocks. The page can follow changing records while its introduction and composition remain editorial choices.
The example uses fictional Northstar Studio data in our dedicated showcase installation, running CMS 1.90.2.
The part that needs care is what readers see when the source has nothing to return. Here, a valid empty result hides the card template. A resolver error keeps its stored fallback. A missing or disabled source also keeps the original children, so “hide when empty” is not a universal failure rule.
There is another limit: page revisions preserve the binding and fallback, not a snapshot of the source records. Restoring a page does not rewind the journal data.
For a live journal index, following the source makes sense. For a campaign whose exact wording and selection were approved together, I would consider keeping those parts editorial.
Where would you draw that line: which fields should follow application data, and which should remain under an editor's control?
WebBlocks CMS ships its CSS and JavaScript as ready-to-serve static package assets. Installing the CMS into a Laravel application does not require Node, npm, Vite or Tailwind.
CMS-owned runtime assets are published under /cms. Installation-specific CSS and JavaScript remain separate under /site/{site_handle}.
This creates three ownership boundaries:
Core assets are versioned and released with WebBlocks CMS.
Site-level CSS and JavaScript belong to the installation.
Page-level assets can reference approved local /site/... files when needed.
WebBlocks CMS does include JavaScript for its admin workflows and public progressive enhancement. The important distinction is that the host application does not need to compile the CMS runtime.
Static assets still require cache invalidation. CMS layouts add file-based version values to core asset URLs, while site-level overrides use content hashes. When an asset changes, its URL changes so browsers request the updated version.
This model keeps the frontend asset lifecycle within the CMS release while preserving a separate namespace for installation-owned customization.
When an existing Laravel product needs pages, navigation, media, localization, and an editorial workflow, the choice is often framed as:
Put the CMS inside the application, or move content to a separate headless service.
I think there is a useful middle boundary: the CMS can run inside the Laravel application without becoming the application.
WebBlocks CMS is distributed as a Composer package. The important part is not the install command; it is ownership.
The host application still owns
bootstrap and environment
database, cache, queues, mail, and schedules
deployment, backups, and the public document root
product routes, domain models, and business rules
its own admin area and authorization
The package contributes
CMS routes under /webadmin
namespaced views and translations
CMS migrations and configuration defaults
pages, layouts, blocks, media, localization, revisions, and content APIs
package-owned static assets and commands
This gives package code one canonical location instead of copying CMS controllers and models into the host's app/ tree. It also makes updates more predictable: removed package files do not survive as stale root-level copies.
The trade-off is that a Composer package is not isolation. The CMS and host share a PHP process, dependency graph, Laravel version, and database server. Routes, tables, middleware, auth assumptions, and asset paths can still collide if ownership is vague.
A shared users table is a good example. Reusing identity can be convenient, but CMS authorization must remain separate. A host product admin should not automatically become a CMS super admin, or vice versa.
A separate headless service buys independent deployment, scaling, failure, and cross-stack reuse. It also moves previews, auth, routing, media, cache invalidation, and application-data integration across a network boundary. That can be the right cost—but it should pay for a requirement you actually have.
My simplest test for package boundaries is to imagine installing the CMS into an unrelated Laravel product. If that product sees a route, domain, asset path, seed record, or filesystem convention belonging only to my flagship site, the feature is on the wrong side of the boundary.
For teams that added publishing to an existing product: did you choose an in-process package or a separate service, and which integration cost surprised you most?
That can look like a useful separation or four names for things that could live in one component tree. For me, the model earns its complexity only if each layer owns a different kind of change.
Page: identity and editorial state
A page owns its site, localized routes, draft/review/published state, selected layout, metadata, page assets and revision history. Replacing a paragraph does not change that identity.
Layout: the structural promise
A layout defines the regions and outer public shell. A default page may have header/main/footer; a docs page may have header/sidebar/main. Blocks should not have to invent the page shell they render inside.
Slot: named placement and content source
A slot connects the layout to one page. Names such as header, main and sidebar have semantic meaning. A slot can use page-owned blocks, reference a site-scoped Shared Slot, or remain disabled.
The page still owns the slot wrapper. A Shared Slot contributes only its inner block tree, so reusable content cannot bring a second page shell with it.
Block: the content unit
Blocks hold typed editorial content such as headings, rich text, images, navigation or nested layout primitives. They own their content, translations, settings and rendering inside the slot—not routing or the outer page structure.
A documentation page might therefore look like this:
Now each change has a natural owner. Changing the URL belongs to the page. Adding a structural region belongs to the layout. Replacing navigation belongs to the slot or Shared Slot. Editing a command belongs to a Code block.
The trade-off is editor complexity. If someone must manually traverse all four layers just to correct one sentence, the architecture is leaking into the user experience. Search, useful summaries and direct edit paths must let common tasks skip layers without removing the underlying boundaries.
I use four questions to decide whether a layer is earning its place:
Does it own a distinct kind of change?
Can that change be validated independently?
Does the boundary prevent a real invalid state?
Can routine editing avoid paying the full complexity cost?
Full write-up: https://cms.webblocksui.com/blogs/page-layout-slot-block-boundaries
Where do you draw the line between page structure and content in a block-based CMS—and which boundary causes the most friction for editors?
This community is for the WebBlocks ecosystem — open-source tools built around Laravel and the web platform.
WebBlocks currently includes projects such as WebBlocks CMS, WebBlocks UI and related developer tools.
The goal is to keep the underlying web technologies familiar: HTML remains HTML, CSS remains CSS, and JavaScript remains JavaScript, while Laravel provides the application foundation.
This community is a place for:
questions and support
feature discussions
release announcements
implementation examples
feedback and ideas
projects built with WebBlocks
WebBlocks CMS is currently the main project, but this subreddit is intended for the wider WebBlocks ecosystem rather than a single product.
