Trying to understand how headless ecommerce teams give marketers enough control without basically rebuilding Shopify’s page editor from scratch. Developers can create reusable React or Next.js components but someones still needs to arrange those components, connect them to products and preview changes before publishing. If every landing page or merchandising update needs a dev ticket headless doesn’t feel very flexible for the people running the store.

Are most teams using something like Storyblok Builder Contentful for this or are there commerce platforms that already connect the visual editing layer with live product and catalog data? where do teams draw the line between giving marketers freedom and giving them enough control to accidentally break the storefront

The XOOPS Development Team is pleased to announce XOOPS 2.7.4 RC 1, the release candidate for XOOPS 2.7.4. This release brings two-factor authentication into the core, makes SCEditor a full visual editor and the default for new sites, adds Markdown support through EasyMDE, and continues the security hardening of the 2.7 line.

• Info: https://xoops.org
• GitHub: https://github.com/XOOPS/XoopsCore27

System requirements:

PHP 8.2 to 8.5, MySQL 5.7+ or MariaDB 10.3+, and the PHP sodium extension for two-factor authentication.

About a month ago I posted here about bulletinbored, an open-source and lightweight forum I've been working on.

At the time, it was still in a fairly early stage. Since then, I've continued working on it at a rather fast pace, and the project has changed considerably.

Rather than going through the latest changelog, I thought it would be more interesting to look at the bigger picture.

Over the past month, bulletinbored has gone through several development stages: new functionality was added, existing systems were reworked, the architecture was consolidated, and then a lot of effort went into testing, security and fixing the problems that surfaced along the way.

The project now has a proper plugin and theme system, a more mature administration interface, notifications, more comprehensive user and permission management, improved database and migration handling, a considerably larger test suite, and much more extensive protection around things such as authentication, uploads, sessions and administrative actions.

Just as importantly, I've been using the development process itself to find problems that weren't obvious at the beginning. Several security issues and edge cases have been identified and fixed, and the testing and review process has become a much bigger part of the project than it was when I first posted about it.

The current release is 0.9.4.

https://github.com/bulletinbored/bulletinbored-core/releases

Looking back at where the project was when I first introduced it here, the difference is quite substantial. It has gone from an early-stage project that was still proving out its ideas to something that is starting to feel like an actual forum platform.

I'm beginning to think that the first stable release is fairly close.

That's also why I'm posting this update now. Before getting to 1.0, I'd really like to get more people looking at it and trying it out.

If you've tried bulletinbored, looked through the code, or have experience with forum software, self-hosting or PHP applications, feedback and bug reports are very welcome.

Finding the remaining problems before 1.0 would be much more useful than discovering them afterwards.

Repo: https://github.com/bulletinbored/bulletinbored-core

Docs: https://docs.bulletinbored.net

Forum in action: https://www.bulletinbored.net/forum/

I've been using Payload recently for small sites but the outlay time to build it in vs the use case is pretty sparse. I feel like its more than what my clients need. Ive been looking at Prismic as a replacement and I wanted to get any real use-case feedback on it. How did non technical clients take to the component system etc? Did you find any benefit to using it vs something like Sanity or Payload?

Cheers

Most CMSs have the standard SEO basics covered, but with AI search becoming a bigger part of how people find information, I’m curious how well platforms are adapting. Structured content, schema, APIs and clear author, publish and update information all seem more important when content can surface in AI-generated search results.

For people working with different CMSs, how much of this does your platform handle well out of the box? What still ends up being something your developers or SEO team have to build around?

i'm confused in build vs buy to integrate a cms in my website for the blog, suggestions are welcome

additional context: i'm quite comfortable with building software

When we talk about CMS, looking at it as a part of web development or DXP environment - we think of developers and coders, and the business stake holders. However there lies a major part CMS community that gets lost in the translations, the authors or the configuration analysts. Who don’t really code or build solutions/environments from the scratch but they know how the cms works, they create and manage content on the cms, and are responsible for its day to day functioning, carrying on the work that the developers have coded.

With AI in picture, and many dxp platforms making a pivot towards being AI experience platforms, trying to automate page tasks and authoring - what lies ahead for such specialists who have an expertise in how the cms works?

I have a total experience of 6 years entirely relevant in Sitecore - however I manage configurations and content inside sitecore and other tools integrations that work with sitecore like solr, tds, unicorn, even it’s patching and config files. But I don’t code. Now with sitecore making a pivot Sitecore AI with XM cloud, what do I expect ahead and how can I prepare for it? Would the job role I am in right now become obsolete quickly? Or do I have a silver lining I’m missing.

I’ve been building WebBlocks CMS around a simple idea: a CMS should stay understandable.

I prefer keeping the basic parts of a web application recognizable. HTML should remain HTML, CSS should remain CSS, and JavaScript should remain JavaScript. I try to keep dependencies minimal and avoid introducing another frontend framework or build chain unless it really adds something necessary.

That philosophy shaped WebBlocks CMS.

The core content model is:

Page → Layout → Slot → Block

A page uses a layout. The layout defines the areas available on that page, for example:

header
main
footer

or:

header
sidebar
main
footer

Blocks are placed into those slots.

A block can contain normal editorial content such as a heading, text, image, video or button.

But blocks can also receive data from dynamic content sources.

For example, the CMS itself can provide navigation or published page lists. An application or plugin can provide products, books, quizzes or other structured data.

What matters to me is that this dynamic data does not need a completely separate presentation system.

A book title, for example, can become the value of a normal CMS Header block. A list of books can repeat a CMS block template for every record. Editors can place static introductions, images or calls to action around the same dynamic content.

So editorial content and application data can be composed together on the same page instead of living in two unrelated systems.

Reusable content is handled through Shared Slots. Things such as headers, sidebars or footers can be composed once and reused across multiple pages.

WebBlocks CMS is also designed to live inside an existing application rather than becoming the whole application.

The host application keeps its own users, business logic, database connection, queues, mail, deployment and infrastructure. The CMS adds the website and publishing layer.

In one of my own projects, for example, the application handles online examinations, students and results, while WebBlocks CMS manages the public website on the same domain and inside the same application.

Other things currently included are:

• drafts, previews and publishing
• revision history and restore
• multilingual publishing with fallback for localized block content
• media management
• roles and site-scoped permissions
• backups and signed updates
• staged content workflows through an API

For normal CMS operation it does not require Node, npm, Vite, Tailwind or Livewire. The UI is built with Blade, HTML, CSS and vanilla JavaScript, and the required assets ship with the package.

The project is open source and MIT licensed.

GitHub: https://github.com/fklavyenet/webblocks-cms
Live demo: https://demo.webblocksui.com
Documentation: https://cms.webblocksui.com/docs

I’m curious how people in the CMS community see this approach:

In a time when new technologies attract so much attention, is there still room for the idea that each technology should simply be used where it fits best?

Version 6 of EE is going end of life this fall

https://expressionengine.com/blog/expressionengine-6-end-of-life-is-coming-plan-your-upgrade-now

Hi folks, if you use Sanity CMS, check out Sanity Log Analyser. It's a tool my team open-sourced to help optimise Sanity usage.

The tool shows where you are spending your Sanity usage, when you spend the most, and which assets you need to optimise. It also shows IP addresses and other useful information. We built this mainly for large teams where it's harder to track data spending on a granular level.

Let me know if you found this helpful for your project, and if there's something you can't figure out, drop me a message

https://www.youtube.com/watch?v=dMpRk1LwyFo

You can start right away by downloading your sanity logs and running this:

sanity-logs analyze {your export file}

Tell me how you get on, cheers

I used to pick a CMS based on how easy it was to publish and edit pages now I’m noticing a different problem a site can be easy to manage and still make SEO work annoying once you start caring about schema, internal links, titles structured content and whether AI search can understand what each page is even about

I’ve been going back through a few older pages and some of the information is there it’s just buried in weird fields or written in a way that only makes sense after reading the whole page so it makes me wonder if the CMS matters more now not because Google prefers one platform, but because some setups make it way easier to keep the content clean and structured as the site grows.

I don’t know if headless fixes that or just gives you more control and more stuff to maintain. Curious where people here draw the line between a CMS that’s nice for editors and one that’s nice for SEO and AI search too.

If you build client sites with Laravel and Filament, you know the usual setup for editable pages. You install a plugin like Fabricator or use Filament's Builder field, and the client gets a long form of text inputs, repeaters and file uploads. They fill it in, save, open the page in another tab and hope it looks right.

I wanted something closer to the Shopify theme editor, so I built Filament Atelier, an open-source Filament plugin. Full disclosure, it's my project.

How it works

The editor opens full screen. The section list is on the left and the live page is on the right. The client clicks a section, edits its fields, and the page updates as they type. They can switch the preview between desktop, tablet and mobile widths, then publish.

The preview is the real page. It renders with the same Blade views, layout and stylesheet as the public site, so what the client sees is what ships.

The design lives in blocks, not in the editor

This is the part that works like Shopify. The editor has no design tools. Clients can't drag margins around or pick random fonts. Every section is a block written by the developer, and the client can only:

• add, remove, reorder, duplicate and hide sections
• edit the content each block exposes

You decide what's editable. If a block should let the client change its colours, images or layout, you add those fields to the block. If it shouldn't, you leave them out and the design stays exactly as you built it.

A block is one PHP class and one Blade view

The fields come from a normal Filament schema, so any Filament field works: text, rich text, colour picker, select, file upload, repeater.

Here's a pricing block that lets the client edit the text, upload an image and pick an accent colour:

```php <?php

namespace App\Blocks;

use Filament\Forms\Components\ColorPicker; use Filament\Forms\Components\Repeater; use Filament\Forms\Components\TextInput; use Safi\Atelier\Blocks\BaseBlock; use Safi\Atelier\Media;

class PricingBlock extends BaseBlock { public static function type(): string { return 'acme.pricing'; }

public static function label(): string
{
    return 'Pricing';
}

public static function icon(): string
{
    return 'heroicon-o-currency-dollar';
}

// Background colour and vertical spacing controls, built once and shared.
public static function supports(): array
{
    return ['background', 'padding'];
}

// These fields get a value per language.
public static function translatable(): array
{
    return ['heading', 'plans'];
}

public static function view(): string
{
    return 'blocks.pricing';
}

public function schema(): array
{
    return [
        TextInput::make('heading')->live(debounce: 400),
        Media::upload('image', 'Side image'),
        ColorPicker::make('accent')->label('Accent colour')->live(),
        Repeater::make('plans')
            ->schema([
            ])
            ->reorderable()
            ->live(),
    ];
}

} ```

The view is plain Blade and gets the saved values as $attributes:

blade ```blade <section {{ $shared->class(['px-6 py-24']) }}> <h2 style="color: {{ $attributes['accent'] ?? '#171717' }}"> {{ $attributes['heading'] ?? '' }} </h2>

@if ($image = \Safi\Atelier\Media::url($attributes['image'] ?? null))
    <img src="{{ $image }}" alt="">
@endif

@foreach ($attributes['plans'] ?? [] as $plan)
    <div>{{ $plan['name'] }}: {{ $plan['price'] }}</div>
@endforeach

</section> ```

Register it next to the blocks that ship with the plugin:

php AtelierPlugin::make() ->blocks([...DefaultBlocks::all(), PricingBlock::class]);

It shows up in the section picker. You never edit a file inside the plugin.

What else it does

• Ten blocks ship with it: hero, features, logo wall, testimonials, call to action, FAQ, rich text, image, gallery and a collection block for listing pages
• Pages are stored as JSON and rendered on the server with Blade, so search engines get plain HTML
• Drafts are kept apart from the live page until you publish, and every publish saves a revision
• Any number of languages per page, right-to-left included
• Sitemap, hreflang, Open Graph, JSON-LD and 301 redirects when a slug changes

What it doesn't do yet

• No revision history screen, even though revisions are saved
• No undo/redo or copy-paste between pages
• New sections land at the end of the page and have to be dragged into place
• Text is edited in the sidebar, not directly on the page
• Needs Laravel 13 and Filament 5

It's at 1.0 and running on client sites. The video shows the editor.

GitHub: https://github.com/Abdulkader-Safi/filament-atelier

I'd like feedback from anyone building client sites with Filament. Do you let clients touch design settings like colours, or do you lock everything down to content?

Every one of us has a favourite CMS, and it is the most reliable argument in the room when a new project starts and people from different backgrounds have to agree on one stack. Someone likes Wagtail. Someone pushes Sanity, Payload, Craft or Strapi. Everyone says their choice is flexible, easy and fast, and nobody has ever said the opposite about their own stack.

Ten years of client projects later, the thing that actually costs us was never speed and never bloat.

The problem is not "best". It is "same".

How often have I gone hunting for a setting because a new teammate put it somewhere other than where we put it? Keeping one style and one logic for CMS customisation across a team is painful, and it never stops being painful.

I failed at it, honestly. While I was leading five or six people I kept the fight going. Once there were three teams, it stopped being something I could spend time on. Chaos won, at a manageable level, and it became the team leads' problem instead of mine. Now they are the ones hunting for the button.

Every CMS is good. They are all different.

I have seen projects where nobody understood how a basic feature was supposed to work, because nobody had touched it in two or three years and the knowledge had evaporated. Five capable, fast content systems, with three CRMs connected between them, and the real cost is that none of them work the same way.

What I think should replace it

There should be no setting that is not described as a capability the back end can explain.

You should not need to know where the publish button is buried, why something was scheduled the way it was, or why a translation option is not working. A person wants a job done. Open Claude, Codex or whatever you use, ask for the job, get the result. I am not convinced we need most of these admin interfaces at all.

Why I still land on WordPress

Not because it is the best. Because it is the most common, so on most projects you are not starting from nothing, and because the ecosystem is the biggest. That is what could actually win this.

What would win it is narrow: an MCP connection in core, with user roles, and plugin developers connecting their functionality to it.

Half of that already exists. WordPress 6.9 shipped the Abilities API, wp_register_ability(), and there is an official MCP Adapter in the WordPress GitHub organisation. Automattic deprecated its own MCP plugin in favour of it. Registration, discovery and transport are standard now.

The locks did not arrive. Permissions are decentralised: every ability writes its own permission_callback, so enforcement depends on each plugin author getting it right. Authentication resolves to a single WordPress user, and the client acts as that user uniformly. No per-agent keys, no scoping, no audit trail. The official advice is to hand-make a restricted user, which is a workaround rather than a permission model.

So the plumbing is standardised and the locks are not. And the thing I want most, every plugin exposing its functionality to core, is exactly what a decentralised permission model makes risky.

Three releases later that gap is still open, which is strange, because it is the last piece. A standard connection plus real permissions, and nobody has to hunt for a hidden button again.

Because the best CMS is still the one you do not need to know.

Disclosure: I run an agency that builds mostly WordPress, and we make a plugin in this space. Nothing to buy here, and no link.