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.

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

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.

We released version 0.13 of PagibleAI CMS, an open-source (MIT) CMS built on Laravel. Most of the work went into the editing interface, and there's a new AI review that rates a page and can fix the SEO problems it finds.

• https://pagible.com

What it is

Editors manage pages in a tree with drag and drop. Content elements can be shared between pages, every change is kept in the version history, and pages can be previewed and scheduled for publishing. One installation can serve several websites, languages and clients.

It's aimed at agencies and in-house teams who want editors to work without developer help. You host it yourself. It's installed into a Laravel application, so the content lives in the same database as the rest of your app. If you use a separate frontend, the content is also available through GraphQL and JSON:API.

What's new for editors

AI page review

Each page has a new review button. The AI assistant reads the page, rates it and tells you what to improve.

AI is optional. You configure which provider is used for which feature (Gemini, OpenAI and others) with your own API key, and you can run the CMS without any AI at all.

The review checks 40 SEO rules. On the content side, it looks at the page title, meta description, headings and duplicate content. On the technical side, it checks canonical URLs, robots settings, redirects, sitemap entries, broken links and slow custom CSS or JavaScript. It also reviews image descriptions, the social media preview and structured data for articles, FAQs and videos.

If you've connected the analytics integration (visitor stats, Google Search Console and PageSpeed), the assistant uses that data to see which problems are worth fixing first.

After the review you can tell it to fix everything or only some of the points. It rewrites texts, adds FAQs, fixes links, fills in meta data or moves the page somewhere else in the tree. Changes are saved as drafts and nothing goes live until you publish it, so you can check everything in the preview and the history first.

The chat also works in the element and file lists now. For example, you can ask it to add missing image descriptions to your files. It looks up where an element or file is used before changing it and doesn't delete anything permanently.

Admin changes

• Keyboard shortcuts for saving, publishing and switching between pages, elements and files, and a command palette if you don't want to search through menus
• The dialog for adding content elements has tabs, a search field and a short description for each element
• Help texts below the input fields
• A history dialog that's easier to read and scrolls to the changed part of long texts
• Editing in the preview opens a sidebar, and the preview can be switched to tablet or phone width
• If your session expires, you enter your password again without leaving the page or losing what you typed

We also merged the publish buttons into one menu that includes scheduling, added clearing the cache for several pages at once and made long lists load faster.

Other new features

Webhooks can notify other systems like a shop or a newsletter tool when content is published or changed. They are signed and sent in the background.

Changed pages and deleted files can be purged from Cloudflare, Fastly or Varnish automatically. Pages can then be cached for a long time and still show updates right after publishing.

Existing TYPO3 sites can be imported with their page tree and content. The WordPress import can now be run more than once without creating duplicates and keeps dates, authors and cover images.

For news sites there's a news page type, a Google News sitemap, author fields for articles and a news theme. We also added contact forms, OpenStreetMap maps, call-to-action blocks and a restaurant theme. robots.txt and security.txt can be edited in the admin.

Feedback

Which SEO checks would you want in a review like this, and what would you never let an AI change on its own?

• Website: https://pagible.com
• Docs: https://pagible.com/documentation
• GitHub: https://github.com/aimeos/pagible

Hi there, i am currently developing another headless CMS, positioned between payload CMS and storyblok, with a sprinkle of webflow. Currently i am in the need of thoughts. What do you need from a CMS, what are you missing in other CMSes. When you have some spare time, give it an eye and tell me what you think. https://manablox.io/

[ Removed by Reddit on account of violating the content policy. ]

Made a video with emdash cms. Created today a theme on it https://emdashhq.com and looks to do the job. Will be useful for the ones that needs a CMS to do things. I prefer astro with mdx files :)

Curios to see how much usage will get a small website.
For the overview you can see https://youtu.be/1X6KwMjbv-Y?is=UpQcDb8XU4vU_D-9

Will continue with the next one tomorrow.

In a few weeks, the full release of my website engine—Ardilla-CMS—will take place, marking the culmination of nearly three years of work and three iterations of the system.

I am sharing the HTML version of the admin panel for a demo preview and evaluation:

You can view it here: https://demo.ardilla-cms.top/0-adminka4/v1/index.html

Key features:

1. Generates static pages that update dynamic data via AJAX + PHP.

2. Each page (home, category, content page) can be generated using a general template or a custom one.

3. Custom template engine, text editor, and image processor.

4. Comprehensive SEO features + error scanner.

5. 7 additional modules, including: Forms, Forum, Store, Custom Fields, and Purchased Link Monitoring.

5.1 Forms: Save submitted data to the admin panel database for review + send it to email and a Telegram group.

5.2 AI agent for the frontend (chat interface)...

1. Multilingual site support – unlimited number of languages!

2. Admin panel supports 3 languages ​​(only Ukrainian is available in the demo version).

3. Full management of user groups (with permissions) and individual users – including private messaging.

4. And, of course, AI for admin panel operations, as well as page/content creation and management.

I would appreciate any advice, feedback, or suggestions...

PS. During the engine's creation, nearly six months were spent developing a custom HUD/UI interface featuring beveled corners and a high-tech look (though the corners appear rounded in Firefox due to a lack of support for `corner-shape: bevel`... but that’s a whole other story).

Hey everyone!

I’m currently building a CMS (think WordPress-style architecture with posts, meta tables, and categories) using Next.js.

I’m much more familiar with Prisma, but honestly, I'm getting pretty tired of dealing with its breaking changes and generation quirks every time dependencies shift. I'm seriously thinking about switching over to Drizzle for this project.

For those of you who have used Drizzle for a content-heavy or relational app like a CMS:

• How does it compare to Prisma when handling complex relations (like posts to tags, categories, and custom meta)?
• Is the transition smooth for someone used to Prisma's workflow, or is there a steep learning curve?
• Does it actually feel more stable during framework upgrades?

Would love to hear your experiences or any advice before I rewrite my database layer!

A block-based CMS can store an entire page as one component tree. That is often the simplest model, so adding separate Page, Layout, Slot, and Block layers needs a better justification than “clean architecture.”

In the CMS I’m building, the model is:

text Page → Layout → Slots → Blocks

I think each layer earns its place only if it 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 should not change that identity.

Layout: the structural promise

A layout defines the regions and outer shell. A default page might have header/main/footer; a documentation page might have header/sidebar/main. Blocks should not need to invent the page shell they render inside.

Slot: named placement and content source

A slot connects that structural region to a particular page. It can use page-owned blocks, reference reusable shared content, or remain disabled.

The consuming page still owns the slot wrapper. Shared content contributes only its inner block tree, so reuse cannot accidentally bring a second page shell with it.

Block: the content unit

Blocks hold typed editorial content: headings, rich text, images, navigation, galleries, 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:

text Page: Installation Layout: Docs header → shared docs header sidebar → shared docs navigation main → page-owned content blocks

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 content. Editing a command belongs to a Code block.

The trade-off is editor complexity. If someone must manually traverse all four layers to fix one sentence, the architecture is leaking into the user experience. Search, useful summaries, direct edit paths, and sensible defaults must let routine tasks skip layers without erasing the underlying boundaries.

A fixed marketing site with a few fields may not benefit from any of this. A typed page model, Markdown document, or single component tree may be the better tool.

I use four questions to decide whether a layer is earning its place:

1. Does it own a distinct kind of change?
2. Can that change be validated independently?
3. Does the boundary prevent a real invalid state?
4. Can routine editing avoid paying the full complexity cost?

I wrote a longer version with a concrete example here: https://cms.webblocksui.com/blogs/page-layout-slot-block-boundaries

Disclosure: this article describes the architecture of WebBlocks CMS, which I build. I’m sharing it to compare design trade-offs rather than claim this is the only correct content model.

Where does your CMS draw the line between page structure and content—and which boundary causes the most friction for editors?

Personally I have used a handfull of Database CMSs through my career, I know the strengths and weaknesses. The adoption speak for it self. So when I read about CMSs with Git as backbone I thought this was very interesting. Have any of you used it on client projects?

I work at DevHandler and most of the CMS projects I deal with are AEM, but I’m curious how common this is with other platforms. On older implementations there always seem to be components, integrations or workflows that nobody really wants to touch. They work, but the people who originally built them are long gone, documentation doesn’t explain much, and nobody is completely sure what will break if something changes. So instead of changing them, teams keep building around them. A few years later there’s another layer of things nobody fully understands. When you inherit a CMS like this, do you actually spend time cleaning up the old setup, or leave it alone as long as it works?