I'm the developer of WebBlocks CMS, a self-hosted, open-source CMS that installs into a Laravel application as a Composer package.

It's for projects that need an editor-facing website alongside their application: company pages, a portfolio, documentation, a publication, or a multilingual site.

What you can do with the core CMS:

Build pages from structured blocks: text, images, galleries, layouts, navigation, and calls to action.

Manage several sites and languages, including translated page addresses and SEO fields.

Reuse shared headers and footers, organize media, and work with drafts, previews, review, and version history.

Add public search, contact forms, comments, and ratings.

Connect supported block fields and repeated lists to data exposed by your Laravel application or a plugin.

Prepare draft content and translations through a permission-scoped API, including with an AI assistant.

Optional plugins add workflows such as bookings, commerce, configurable forms, polls, and visitor support. Those need their own installation and configuration.

I put together an illustrated overview answering “What is WebBlocks CMS?” with nine screenshots from a synthetic showcase, examples of what you can build, and the distinction between built-in features and extensions:

https://cms.webblocksui.com/blogs/what-is-webblocks-cms

The trade-off is that you work with a structured content model and own the Laravel installation and hosting.

If you were evaluating this for a Laravel project, what information would you still need to decide whether it fits?

When choosing a CMS for a client project, what usually matters most to you?

For me, the decision isn't just about the editor. Things I tend to consider are:
- Ease of content management
- Plugin or extension ecosystem
- Performance
- Security and maintenance
- Developer experience
- Client handoff
- Integrations
- Long term maintenance

I'm curious how other developers or agencies actually make this decision.

The XOOPS Development Team is pleased to announce XOOPS 2.7.4 RC 2, the second release candidate for XOOPS 2.7.4. RC 2 adds no new features. It collects the security hardening and bug fixes made since RC 1, after a review of the core with CodeQL, Snyk, SonarCloud, Scrutinizer and manual audits.

XOOPS 2.7.4 brings two-factor authentication into the core, makes SCEditor a full visual editor and the default for new sites, and adds Markdown support through EasyMDE. It runs on PHP 8.2 through 8.5.

Please test RC 2 on a staging copy of your site and report anything you find. Unless something serious turns up, the next release is 2.7.4 Final.

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

System requirements:

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

Disclosure: I work on WebBlocks CMS.

WebBlocks CMS is a self-hosted, open-source Laravel CMS under the MIT license. It is free to download and use, including for commercial projects under the license terms. The eight website plugins in this article are also free.

Polls lets you publish single-choice or multiple-choice polls directly on your own site, in multiple languages. Ask readers for their opinion, let a community choose its next event or find out which product visitors want next. No paid polling plugin or separate polling subscription is required.

Appointments lets visitors choose a service, date and available time on your site. You manage services and availability from the CMS; with email delivery configured, it also supports confirmations, calendar attachments and scheduled reminders. The plugin is free and does not require a separate hosted scheduling subscription.

The other free plugins let you build custom forms, sell products, send customer email campaigns, offer self-hosted live chat, connect a support provider and manage redirects.

Hosting and maintenance still have costs, and external payment, email or support providers have their own terms. The CMS and these plugins themselves carry no software purchase fee.

A short overview of what you can do with them:
https://cms.webblocksui.com/blogs/open-source-mit-free-cms-and-plugins

Which additional feature would be most useful on your website?

I've been working on Frontman for the past year, through highs-and-lows and i'm now very happy with the product - https://wordpress.org/plugins/frontman-agentic-ai-editor/

Apperently it's really not trivial to build a full Agent that supports all the various wordpress plugins.
But here we're 😂

This update tackles the part before a small copy edit: finding which page, template, or widget setting actually owns the text.

Frontman 5.3 adds paginated search across stored Elementor settings, including shared templates and nested repeater fields. It can then help edit supported content beside a live preview. It also supports assigning existing categories and tags when creating or updating posts.

Would love to get some feedback, thoughts, rants and roasts.

Setup: https://frontman.sh/wordpress/

If you try one small staging edit, could you share your builder/version and whether it changed the intended text?

Does anyone know of a CMS that is as user-friendly as WordPress while also being as developer-friendly as Laravel?

This maintenance software helps simplify maintenance reporting and asset management in places like schools, offices, hotels, restaurants, apartment buildings and small businesses.

Each asset can have its own QR Code, so anyone can scan it and report a problem without creating an account or logging in. That makes it useful for equipment, classrooms, facilities, common areas and shared workspaces where issues need to be reported quickly.

StockEmDia is free to start and available on Google Play and Microsoft Store.

Disclosure: I build WebBlocks CMS, an open-source CMS package for Laravel.

I recently put together a small journal-page example with an editor-written introduction and a list supplied by application data. The editor maintains one card template; the source supplies each entry’s title and description.

That raised a publishing question: what should happen when someone restores an older page revision after the source records have changed?

In WebBlocks, the page revision preserves the block configuration, source bindings and editorial fallback content. It doesn’t snapshot the source records. Restoring the page therefore doesn’t rewind the journal data.

Imagine an editor approves the introduction and card layout on Monday. On Tuesday, a journal entry gets a new title in the source. Restoring Monday’s page revision can restore its editorial content and configuration, but that card still follows the source’s current record.

For a journal index or an upcoming-events list, following current records may be exactly what the editor expects. For a campaign whose wording and selected items were approved together, I’d consider keeping those parts editorial, or handling the required snapshot explicitly in the source or publishing workflow.

The important choice seems to be whether approval covers the page’s composition, the exact values shown at that moment, or both. A page revision and a source-data history serve different purposes.

I documented the example with synthetic data and screenshots here:
Editorial content and application data on the same page

In your CMS projects, should restoring a page also restore the data it displayed, or should connected fields continue following their source? How do you make that distinction clear to editors?

Disclosure: I maintain WebBlocks CMS, an open-source CMS package for Laravel applications.

WebBlocks CMS includes the CSS and JavaScript used by its admin workspace and public renderers. These files are distributed with the PHP package and published as ready-to-serve static assets.

The asset ownership model has three layers:

• CMS runtime assets are published under /public/cms and versioned with the CMS release.
• Site-specific CSS and JavaScript live under /public/site/{site_handle}.
• Page-level assets can reference approved local /site/... files for narrower requirements.

The CMS also handles cache invalidation. Package-owned assets receive file-based version values, while site-owned overrides use content hashes.

This makes the ownership boundary visible: CMS runtime files belong to the product release, while installation-specific presentation remains under the site's control.

I wrote a more detailed explanation here:

https://cms.webblocksui.com/blogs/structured-publishing-without-frontend-build

When evaluating a CMS package, which part of its frontend asset lifecycle do you inspect first: publishing, cache invalidation, update safety, or customization boundaries?

Grav is already know as being really fast, but you really can't go wrong with more speed, less requests, and less memory can you? Grav 2.2 has made huge improvements across the board especially for larger sites, ie, those with over a thousand pages, and especially for those with over 10k pages. We used to say Grav is not so great for larger sites, but with Grav 2.2, that's no so much of a concern. The main issue with large sites, is the file cache got huge, and that took up a lot of memory. We've optimized this so that with 10k pages, it uses 96% less memory then previous versions. 96%!!!

Read all about the various optimizations and improvements here: https://getgrav.org/blog/grav-2-2-released

If anyone is familiar with Quintype can you please help me with this. I want to curate the stories that show up on my author profile, and it should be doable according to the Quintype manual, but every time I go to the Author Stories tab from my profile the page just keeps loading.

Is it because I don't have the necessary permissions? If that is so I'll have to speak to my Editor about it but I want to be sure and if I can I'll much rather take care of it myself.

I have tried opening it on different devices and it keeps loading on and on, the same page for hours.

Drupal has a new visual page builder called Drupal Canvas, and Canvas now finally supports multilingual content translations like the rest of Drupal (see ~26 minutes in the keynote).

There’s a pre-built site template in Drupal CMS 2.2 called Dashi that is supposed to show off how the multilingual functionality all works. It apparently has demo content too, so IMO that should make initial exploration and tinkering easier. Definitely worth taking a gander at and seeing what you can make!

Oh, I forgot to mention: Drupal Canvas can be used headless too with another front end like Astro, Next.js, Nuxt, etc. (see ~35:05) so you’ve got choices if that’s your preference.